[teampractices] Defining "Interrupt" work

[Kevin Smith]

I think I understood Terry's buckets to be:


   1. Keep the lights on and servers running, assuming nothing external
   impacts them.
   2. Respond to external events, such as security patches and library
   upgrades.
   3. Innovation.

I believe DStrine recently created an "Unplanned" tag in phabricator, which
certainly sounds related. In that case, I believe the definition was "Work
we added to this sprint after this sprint started." Which seems like an
entirely reasonable definition, for teams doing timeboxed iterations as in
Scrum.

I think my existing discomfort with the conversations so far about
"interrupt" work boils down to not knowing if it is "unplanned" work,
"externally triggered" work, or "not part of our long-term goals" work. Or
some combination of those.





Kevin Smith
Agile Coach
Wikimedia Foundation



*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*

On Wed, Aug 5, 2015 at 11:31 AM, Joel Aufrecht <jaufrecht at wikimedia.org>
wrote:

> I'm working on a definition of "interrupt" work that we could standardize
> and measure across the Foundation.  The purpose is to inform planning; in
> particular, we probably have a lot of teams thinking they can, or being
> asked to, complete a certain amount of new work, without fully taking into
> account the amount of maintenance work that will continue arriving.
>
> I'm starting by collecting information and opinions.  Here's what I have:
>
> 1) Terry has three buckets, but I don't have their exact names or
> definitions
>
> 2) I've been thinking roughly, "work that has to be done to maintain
> existing products and services at their current level of
> functionality/performance/success".
>
> 2a) The question of "success" is interesting; if a product starts losing
> market share, is work to keep market share up "interrupt"?  I think it
> isn't, and the "output vs outcome" divide applies here.  If the output (a
> service being available) breaks, fixing that is interrupt, but if an output
> becomes less popular, making it more appealing is not interrupt.
>
> 2b) What about patching and upgrades?  Is a patch "interrupt", but an
> upgrade to support a new version of Windows not?
>
> 3) Some notion of planned vs unplanned?  Is the essence of interrupt work
> that it's unplanned?  Or are "maintenance work" and "unplanned work"
> distinct; it just happens that a much bigger percentage of maintenance work
> is unplanned compared to new-functionality work?
>
> 4) Is there any definition from MPL work?
>
> 5) Are any teams other than VE experimenting with this distinction in
> their backlogs?
>
> (Tracking: https://phabricator.wikimedia.org/T107824)
>
>
> *Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150805/49ce73b9/attachment.html>