[teampractices] Defining "Interrupt" work

Wed Aug 5 20:47:14 UTC 2015

So I would say the buckets are about rat but I would certainly welcome some
feedback on how we make definitions that are good for engineering..

If I use my house analogy..

Bucket 1 is CORE - It is paying the mortgage, the property tax and copying
with HOA rules and local ordinance and building codes
Bucket 2 is Maintenance - Painting the house every 5 years, putting a new
roof on every 20 years, cutting the grace one a week.. All of this you can
postpone but typically there is a cost increase to not doing that you
eventually have to pay for later. EG it will take longer to get the lawn
back in shape if you let beth grass go to seed or the painting of a house
takes longer if you have to replace woodwork etc due to rot.
Bucket 2 - Investment / new projects - This is remodeling the bathroom..
highly optional but makes like easier and could improve the overall value
of the house..

Be interesting to get engineering analogy for this.. - Thoughts?

Interrupt work would, to me, mean "unplanned". Examples are.. a hail storm
that damages the roof.. a tree that falls over...

Does that help any?

On Wed, Aug 5, 2015 at 1:05 PM, Kevin Smith <ksmith at wikimedia.org> wrote:

> 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
>>
>>
>

-- 
Terence (Terry) Gilbey
Chief Operating Officer
Wikimedia Foundation
149 New Montgomery Street
San Francisco, CA 94105

(626) 222 5230
tgilbey at wikimedia.org <kmaher at wikimedia.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150805/498cc3a5/attachment-0001.html>