<div dir="ltr">The only thing I have to add is .... "What Joel said".. as he made the case more eloquently than I do.. </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 11:00 AM, Joel Aufrecht <span dir="ltr"><<a href="mailto:jaufrecht@wikimedia.org" target="_blank">jaufrecht@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>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?</div></blockquote><span><font color="#888888"><br><span style="color:rgb(0,0,0)">The top two reasons for me:<br>1) In order to forecast when the VisualEditor team may complete new functionality milestones<font color="#888888"></font>, I need to understand what fraction of their velocity is consumed by maintenance work.<br><br>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.<br><br>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.)<br><br>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:<br><br><b>Planned vs Unplanned</b><br>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.<br></span></font></span></div><div><span><font color="#888888"><span style="color:rgb(0,0,0)">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.<br></span></font></span></div><div><span><font color="#888888"><span style="color:rgb(0,0,0)"><br><b>Maintenance vs New Functionality</b><br>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.<br><br><b>Bug vs Feature</b><br>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.<br><br></span></font></span></div><span style="color:rgb(0,0,0)">So I'm leaning toward a default recommendation of:<br>1) Try to track the three buckets (core, maintenance, new functions), and try to confirm that teams can actually differentiate between them cleanly enough<br></span></div><span style="color:rgb(0,0,0)">2) don't track bug vs feature<br></span></div><div><span style="color:rgb(0,0,0)">3) don't track planned vs unplanned, but do be careful not to automatically conflate unplanned with maintenance.<br><br></span></div><span><font color="#888888"><span style="color:rgb(0,0,0)"><font color="#888888"></font>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.<br></span></font></span><div><div><div><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">--<br><span style="color:rgb(0,0,0)"></span><b>Joel Aufrecht<br></b><div><div><div dir="ltr"><font color="#888888"><div>Team Practices Group<b><br></b></div><div>Wikimedia Foundation<br></div></font></div></div></div>
<br></div></font></span></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font color="#999999">Terence (Terry) Gilbey<br>Chief Operating Officer</font><div style="color:rgb(136,136,136)"><font color="#999999">Wikimedia Foundation<br>149 New Montgomery Street<br>San Francisco, CA 94105</font></div><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)">(626) 222 5230</div><div style="color:rgb(136,136,136)"><a href="mailto:kmaher@wikimedia.org" style="color:rgb(17,85,204)" target="_blank">tgilbey@wikimedia.org</a></div></div></div></div></div>
</div>