Getting DEEP with your backlog Part 2

Estimation is not rocket science

Last week, I began my discussion about how to be a better product owner.  I am using Roman Pichler’s DEEP approach to making the product backlog more useful.  Last week, I discussed how a backlog should be detailed appropriately.  This week I am covering estimation.

Estimation has gotten to be a dirty word among many technical professionals.  They are treated as quotes by business owners.  Estimates are often lies we tell ourselves and employers about how difficult a task can be.  So as a product owner, when you ask a development team to estimate you will often receive eye rolls and sarcasm.

The reality is, if estimation is done correctly, it can be a useful tool in planning work.  Each time a story is authored and placed in the backlog, the development team should attempt to estimate the story.  If the story is not detailed appropriately, the story is stent back to the product owner to be further refined.

If a story has enough detail them team should estimate it with story points.  Story points are a function of difficulty of a task and the uncertainty surrounding it.  Don’t consider it a measure of time but treat it like a measure of distance.  An Olympic runner can run a mile in under four minutes.  A man like me can walk it in about thirty minutes.  Considering the wide range of skills on many development teams, I may take one developer eight hours to complete a story point and it will take a different developer four.  Time is not the issue because complexity and uncertainty are the key factors.

Once a team begins estimating stories, you can experiment with team velocity.  If your team can do between 30 to 40 story points a sprint with a little simple arithmetic you can project out how long it is going to take you to finish.  For instance, if you have a 150 story point in your backlog in a worse case scenario you know it will take five sprints to complete the work while it will take four sprints in the best circumstances.

It may not be realistic for the team to have each story estimated so the rule of thumb I have discovered is you should have two sprints of work estimated.  You will have a good flow through the project.  You will also be able to answer the question your business partners care about most; when will the team finish and how much is it going to cost.

So that is why a product backlog should be estimated because it makes it easier for a team to budget its work.  An estimated product backlog also allows you some ability to forecast when the team is going to finish its work.  Finally, estimates are not hours treated as a quote but rather points which are a function of complexity and uncertainty.

So by having a backlog detailed appropriately and estimate you are going to be more successful as a product owner.

Until next time.