> > I'm not certain I understand the need to draw a distinction between > maintenance and new work. I prefer to think purely in terms of what work is > the most strategic in terms of achieving our mission; for the purposes of > that, whether work is "maintenance work" or "new work" is irrelevant, as > all that matters is if the work is the most strategic. Is there any > background on why you are being asked to make this distinction? >
The top two reasons for me: 1) In order to forecast when the VisualEditor team may complete new functionality milestones, I need to understand what fraction of their velocity is consumed by maintenance work. 2) Lila and Terry would, as I understand it, like to differentiate types of work during quarterly planning and goal setting in order to understand more project the Foundation's capacity for new functionality. I think this is basically 1) but at a bigger scale. Terry may want to weigh in further on why. My understanding is that goals and plans at WMF are often made based on a notion of engineering capacity that ignores maintenance load, and so are unrealistically optimistic. (Of course there are many other reasons software forecasting tends to be unreasonably unrealistic.) I'm also coming at the issue from the other end: what patterns exist in peoples' work habits and the data, and what questions might we be able to answer from the data we have or can relatively cheaply get? I'm seeing several patterns worth thinking about, either because they are directly valuable to measure, or because they confound and confuse other measures and need to be clarified: *Planned vs Unplanned* This may be more useful as a tactical diagnostic. That is, you may want to measure how much of your day is under your control, and if the result doesn't match your role, change something; and teams might want to check this to see if they are handling more interruptions than they expect. This can help with the "stitch in time saves nine" heuristic, e.g., is it cost-effective to invest in permanently solving an intermittent problem or is it actually infrequent enough that 8 hours of preventative care would only save 2 hours of crisis in the next 5 years? I don't see "interruption rate" as a strategic thing to measure BUT it overlaps so much with Maintenance that they are easily confused. In fact, we've been measuring "Interrupt" for VE when what we mostly want to measure is probably Maintenance. Unplanned can also be useful to measure re: new functionality, as a measure of how accurate a team's initial work breakdown or estimate is compared to what is finally shipped. *Maintenance vs New Functionality* Terry's divisions (core aka "keep the lights on", maintenance, new functionality) can all be thought of in terms of, how much time do we have to complete this before something bad happens? If you think of leadership as the art of "disappointing people at a rate they can absorb", then having this information supports the decision of who to disappoint next. I do see gray zones between the categories, so I'd love to hear more cases for having two buckets versus three buckets versus something else. *Bug vs Feature* I haven't yet seen any teams at WMF maintaining the distinction. Some possible uses of bug lists that don't contain feature work: identifying root cause patterns of preventable problems; comparing # and rate of found bugs to predicted numbers of unfound bugs; identifying the cost of fixing bugs and comparing that to the cost of improving processes enough to reduce bug rates. So I'm leaning toward a default recommendation of: 1) Try to track the three buckets (core, maintenance, new functions), and try to confirm that teams can actually differentiate between them cleanly enough 2) don't track bug vs feature 3) don't track planned vs unplanned, but do be careful not to automatically conflate unplanned with maintenance. This is just a starting point; I'm sure each team is different enough that it will be a challenge to find any definitions that are usable and meaningful across all team. -- *Joel Aufrecht* Team Practices Group Wikimedia Foundation
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
