<div dir="ltr">Note: we are collecting data and open questions (such as definitions) <a href="https://www.mediawiki.org/wiki/Team_Practices_Group/Measuring_Types_of_Work">here</a>.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font color="#888888"><div><b>--<br>Joel Aufrecht<br></b></div><div>Team Practices Group<b><br></b></div><div>Wikimedia Foundation<br></div></font></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 30, 2015 at 4:14 PM, Antoine Musso <span dir="ltr"><<a href="mailto:hashar+wmf@free.fr" target="_blank">hashar+wmf@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le 30/10/2015 20:39, Kevin Smith a écrit :<br>
> There is an initiative within the WMF to figure out how much time/effort<br>
> teams spend on "new functionality" vs. "maintenance". As a pilot<br>
> project, I have been tracking that in our Discovery Cirrus project[1]<br>
> for a couple months.<br>
><br>
> As shown on this graph[2], we have been spending somewhere between 25%<br>
> and 50% of our time on "maintenance". Note that this should not be<br>
> considered at all scientific. For starters, there are several glaring<br>
> issues with this graph:<br>
><br>
</span>>   * Because we are not doing point estimation, this graph is based on<br>
<span class="">>     task counts, not actual effort.<br>
</span>>   * Data around Oct 1 is missing/funky due to the offsite.<br>
>   * The bars are pure percentages, so 50% of 2 tasks completed would<br>
<span class="">>     look the same as 50% of 40 tasks completed. That 100% bar, in<br>
>     particular, is misleading because I believe it is based on a single<br>
>     task being resolved that week.<br>
</span>>   * The counts are based on my snap decision for each task, whether to<br>
<span class="">>     add the #worktype-new-functionality or the #worktype-maintenance tag.<br>
><br>
> Still, it's a higher fraction than I would have guessed.<br>
><br>
> Is it worth my time (or someone else's) to continue to track this data?<br>
><br>
><br>
> [1]<br>
> <a href="https://phabricator.wikimedia.org/tag/search-and-discovery-cirrus-sprint/" rel="noreferrer" target="_blank">https://phabricator.wikimedia.org/tag/search-and-discovery-cirrus-sprint/</a><br>
> [2] <a href="http://phlogiston.wmflabs.org/discir_maint_count_frac.png" rel="noreferrer" target="_blank">http://phlogiston.wmflabs.org/discir_maint_count_frac.png</a><br>
<br>
</span>Hello,<br>
<br>
For Release Engineering, Greg Grossmeier came up with a spreadsheet that<br>
lists as columns:<br>
<br>
- our key projects (features<br>
- maintenance<br>
- non sense<br>
<br>
And rows are the team members.<br>
<br>
We each fill a percentage in each column (total 100%) and at the bottom<br>
we have a sum of team overall time per project. Something like:<br>
<br>
         | Scap3 | CI  | Maint. | Non sense |<br>
---------------------------------------------<br>
Antoine  |   0%  | 50% |  40%   |   10%     |<br>
John Doe |  90%  |  5% |   0%   |    0%     |<br>
---------------------------------------------<br>
Total:   |  90%  | 55% |  40%   |   10%     | <-- max 200%<br>
Average: |  45%  | 27% |  20%   |    5%     | <-- average<br>
---------------------------------------------<br>
<br>
That is done at the beginning of our weekly meeting and only takes a<br>
dozen of seconds.<br>
<br>
The main advantages are:<br>
<br>
* easy to get the data<br>
* fast to fill and actually fun since the spreadsheet is shared and show<br>
activity of others<br>
* time based<br>
<br>
Cons:<br>
<br>
* inaccurate, but as you said unless we keep track of what we do every<br>
15 minutes...<br>
* biased by human perception / not based on any fact<br>
* a week-end passed<br>
<br>
I still think it provides useful value. After all if a team perceives it<br>
is spending lot of time on maintenance, that would explain why members<br>
bitch about not being able to produce features.<br>
<br>
Or if you get a ton of outages and issues filled but none of the team<br>
members doing Maintenance, that would help refocus the team as well.<br>
<br>
Organization wide, I believe all the inaccuracies offset each other and<br>
the aggregate would probably ends up being accurate.<br>
<br>
<br>
At another place, we filled a rough estimate of time spent whenever<br>
commenting on a task.  At the end we could roughly estimate how much<br>
time got spent and given the category/tags that could be aggregated.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Antoine "hashar" Musso<br>
<br>
<br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</font></span></blockquote></div><br></div>