[teampractices] Defining "Interrupt" work

[Bryan Davis]

On Wed, Aug 5, 2015 at 12:31 PM, 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)

As someone who mostly does "interrupt" work, my definition for it is
"work that you didn't know when you started your day that you would
have to do". For me this is mostly must fix bugs in production, beta
cluster and/or mediawiki-vagrant combined with tasks that were blocked
waiting on some other entity that are suddenly in need of further
attention.

My personal historical experience both here and at prior jobs is that
planning for this is a matter of heuristics at best. Having
teams/individuals track the amount of work of this type that they
experience for a month or two can lead to a baseline estimate of the
number of hours per week it typically takes.

Bryan
-- 
Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855