[teampractices] Defining "Interrupt" work

Wed Aug 5 18:31:05 UTC 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150805/332b7376/attachment.html>