<div dir="ltr"><div><div>I think it is good to frame time as a budget, because it is a finite resource. Then the mantra becomes "I need to spend less" rather than "I need more resources."<br><br></div>Hofstadter's Law (a favorite) relates better to our previous point on measuring capacity. Estimating task size and complexity is a key part of measuring capacity. Our bullet points earlier in the thread talk about gaining forecasting accuracy over time, and subsequently adjusting batch size with each iteration, to get a better understanding of how long it takes to do something in one loop. Then re-prioritize accordingly, with the umbrella understanding that finishing (or totally abandoning) work is usually a higher priority than starting and stopping.<br><br></div>Jim Benson wrote an excellent book [1] on biases that talks about differentiating "prediction" from "estimation." Prediction is the act of aiming with the hope you are right, where estimation is is the act of aiming with the understanding that you are wrong. The former points you towards a status quo and disappointment when it is not met, where the latter prepares you for inevitable change. It's a subtle difference that can really help to focus on when trying to inspect and adapt properly.<br><br>[1] <a href="https://www.mediawiki.org/wiki/Team_Practices_Group/Recommended_Reading#Agile_.28general.29">https://www.mediawiki.org/wiki/Team_Practices_Group/Recommended_Reading#Agile_.28general.29</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 12:14 PM, S Page <span dir="ltr"><<a href="mailto:spage@wikimedia.org" target="_blank">spage@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"><span class="">On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div> I'm imagining someone whose "todo" queue is growing linearly while their "done" pile eternally remains empty. It seems odd that new higher-priority work would be coming in so fast 
that not only can the old work not get done first, but the new work 
can't either. <br></div></div></div></div></blockquote><div><br></div></span><div>The problem for me comes from ruthless prioritization vs. dealing with new small inbox issues in the moment. I'm sure I read some advice to do the latter instead of the overhead of managing an enormous growing pile of postponed work. Especially with documentation, tagging yet another mail thread "ought to document this nugget some day" vs. spending just-a-little-bit more time getting it done here and now. The problems are<br>a) If there are too many small things you can get done in the moment, then those moments take over your day.<br>b) Hoftstadter's Law [1].<br><br>I guess the answer is to budget your time better. Thanks for any advice, though I don't expect any because answering this is not in your quarterly goals or current sprint :-).<br><br>[1] "It always takes longer than you expect, even when you take into account Hofstadter's Law."
<a href="https://en.wikipedia.org/wiki/Hofstadter's_law" target="_blank">https://en.wikipedia.org/wiki/Hofstadter's_law</a><span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">=S Page  WMF Tech writer<span></span></div></div></div></div></div></div>
</font></span></div></div>
<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>
<br></blockquote></div><br></div>