Story Points and Man Hours – When To Use Them and Why?

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today.

Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be  done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.

Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.

1. Agile Estimation: 9 Reasons Why You Should Use Story Points
2. Agile Estimation: 8 Steps to Successful Story Point Estimation

Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.

Story point being a coarse grained or rough estimation technique, it helps in long term planning like release planning. Product Owner need not wait for detailed estimates from team to do his release/roadmap planning. Using velocity to do this planning keeps the planning real and honest as it is derived from team data.

We use relative sizing estimation always in our personal lives. Go to a restaurant you order a small coke or large plate of salad.

One the other hand, time based estimation is fine grained. When it comes to sprint/task level, you go for time based estimates for tasks as you have the maximum information/knowledge NOW to make better precise estimates. Deferring finer decision making till LRM(last responsible moment) leads to better agility and predictability. – Focus on details over time as you see in the picture below.

 

I encourage new teams to estimate tasks in hours for two reasons:

1. To know when you’ve reached sprint capacity
2. Helps in getting a better understanding of the stories when you break in tasks and estimate it

I ask teams to do daily re-estimation of the tasks they are working on, which is just a gut feel from task owner of how much time is remaining for each task in progress. Completed tasks are automatically zeroed and not started tasks are left as is with original estimates which was done in sprint planning meeting. I have found this to be the most accurate and useful way of tracking sprint hour burn-down. This level of tracking helps team to self-organise around sprint goals and commitment.

Over time, teams get better in delivering what they forecasted and seeing success every sprint. Task estimation should no longer be necessary as the team will gain a more stable velocity (making capacity planning less/not needed). The team eventually should be able to rely almost entirely on velocity and gut feel for sprint planning assuming you keep the team constant going forward. Also the team will gain better business domain knowledge and a good understanding of the writing style of the PO (making the second point less necessary).

The team have the right to decide to have tasks estimated or not and they should continuously improve their techniques to make them less and less heavy. But the SM’s responsibility is to ensure that they are aware of the sprint’s health all the time.

Estimating is not necessary for producing software. As it is with documentation, estimates by itself will not lead to working software. But they do serve a purpose in your organisation. Hence consider their purpose and then see if there are alternative creative ways of achieving the same.

Concluding Thoughts:

There are certain practices that are important for new teams to perform so they can mature to the point where those practices are no longer necessary. Skipping past some of those practices too early can result in increased failure and disillusionment.