How far should we go with estimates

My colleague Dan North facilitated a session today at ThoughtWorks office in Sydney about estimation, creating an MSL (Master Story List), what Scrum calls Product Backlog and which level of granularity should it be.

Dan started the session with a very interesting metaphor: If we want to calculate the area of a country we can always approximate it by comparing it with something that we know how to calculate... A triangle, for example. Dan used the map of the UK, I'm sorry Dan, I couldn't help myself... I changed it to Brazil... :)

AproxBrazilArea.png

Basically, the area is something in between the areas of MIN and MAX triangles. And it's very easy to calculate the areas of the triangles, right? How accurate is that? Of course it's not 100% accurate, but most of the time we don't need 100% accuracy. We just need to understand the boundaries in order for us to mitigate risks, which have been described as our "fears".


The estimated range also helps us to make decisions. If a client wants to build an application, for example, and after calculating his current operational manual costs and what the application would make him save, he is willing to pay 1 million. But the estimated range is between 4 and 6 millions, this already helps the client to make the decision of not to proceed with the project.

Always bear in mind what estimates are:

"Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain." (wikipedia)

Another pertinent topic during the session was that the Iteration Manager (Scrum Master or XP Coach) should not only be focused on the lower level stories (Product Backlog), but also on the high level project goals and outcomes as well as relating them to the client's and organization's needs and purposes.

Stories can be grouped at a A higher level, which we call a theme. Prioritisation and estimation could also be done at these levels.

IMFocus.png

Some other things that I learned:




Share this story