The need for estimates is a fact of (project management) life, whether you’re using a traditional approach or agile ones. The latter try to do away with any exact numbers and instead use anything from t-shirt sizes over gummi bears to story points and treat the idea of estimates as a tool that is mainly intended for the team. However, as to be seen in this article posted on the ScrumAlliance website on story points versus task hours the matter of concrete time estimates comes up every now and then — there are customers and managers that want it and you have to figure out how your estimate / velocity is related to the team’s capacity for any given sprint. TL;DR:

For me, story point is high-level estimation of complexity made before sprint planning.[…]The task-hour estimation, on the other hand, is a low-level estimation[…]should be done during sprint planning for highest possible accuracy.

But, just like every other project manager, I made the experience that there is no such thing as “highest possible accuracy”, regardless of the number of ‘points’ you’re estimating (three-point estimates, anybody? How does that fit in with agile methods?) What does somewhat “work” (for varying degrees of “somehat”) is measuring how much work is ‘roughly’ possible in an iteration (aka velocity in Scrum) and estimating the ‘entire’ efforts according to the law of big numbers, but this is exactly not task-hour estimation. I’ve also worked with task hour estimates during the sprint planning as well, but I wouldn’t rely on the results. Exchanging estimates between developers (aka planning poker) has the main effect of quickly leading to a common understanding of the tasks that need to be done, which in my experience has much more value than any estimate. The insight that numeric estimates are not all that useful (to say the least) is also discussed in this highly opionated article on stop using story points — this is not about going back to estimating in hours or days, but about teams reaching a level of competence, expertise and confidence in their respective context where estimates are just waste.

However, reaching this transcendental level might be hard to reach for many teams, due to lack of experience or because of other more context dependent reasins. Joachim Seibert discusses in his nice article for the “ObjectSpektrum” magazine (5/12) “Agile estimating in teams” (behind a paywall, unfortunately and only in German, sorry), that if you need to come up with the big number for budgeting, you should strive to look at the entire picture. I.e. estimating the overall effort is more important than trying to completely estimate everything down to the tiniest detail — which isn’t possible anyway. Seibert lists two key ingredients for that: estimating a reference story which you stick to throughout the project and comparing the relative complexity of requirements, essentially sorting them by ‘size’. This is easy to forget with planning poker, but is at the very heart of the two other techniques that Seibert discusses: estimation game (by Steve Bockman, apparently) and magic estimation (by Boris Gloger, AFAICT). Both focus on building a common understanding of the relative complexity of the features to be build and are much simpler to apply to lots of stories. If you add velocity to the picture, i.e. you actively measure how much you can build and you can reach a stable project setup (compare this nice sweet spot for agile methods by Philippe Kruchten), you might be able to end up with something useful from all the effort you put into estimation.

No comments

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.