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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> 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 [email protected] <[email protected]>
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
