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

by Avienaash Shiralige

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.

agile estimation - collective intelligence

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.

 

Focus on detail over time

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.

About Avienaash Shiralige


Avienaash Shiralige is an Agile Coach, Trainer, Business Optimisation and Agile Transformation Consultant @ AgileBuddha. He has been on senior leadership positions in various companies and comes with very rich 17+ years of experience in product and service companies. He has consulted companies in India, US, Europe and Australia on Agile/Scrum/Lean/Kanban and successfully set-up various distributed agile teams across timezones. He can be reached at avienaash@gmail.com.

{ 4 comments… read them below or add one }

Rajat Bhalla March 29, 2013 at 8:26 am

Great post Avienaash. Worth bookmarking and sharing.

I have a question that has been asked to me when practicing the above. When we estimate stories in points and its tasks in hours, would there not be a tendency to back-calculate the number of hours for each story point? In the same vein, its possible that two stories might have the same number of story points but different total of task hours. How do I explain that?

Reply

Avienaash Shiralige March 30, 2013 at 10:20 pm

Thanks Rajat. Relation between points and hours do exist. Some matured scrum teams do start experimenting on this, where-in they come up with a probability distribution curve. It means, one point may take sometimes lesser or equivalent or more than 2 points story.

So these teams define a time range not an absolute number for different point scale. For this you need to have good reliable historical data. These distribution curve would be very specific to boundaries of product domain, technology you are using and that team. It would not be wise to extrapolate this beyond these boundaries.

Thanks,

Avienaash

Reply

Prabhakar Karve March 31, 2013 at 9:33 am

Hi Avienaash and Rajat,
I have found another way to deal with story points and hours estimation quite useful. I advise the teams at Impetus to keep track of story points and actual hours spent on completing the tasks. There are variations in the relationship and we identify those cases where there is a significant variation from the average. We pick these up to discuss during retrospectives and try to explore the reasons. Is it because of experience or exposure levels between developers who normally work on such stories and the one who worked in the current sprint? Did we use a tool or a library which helped us to substantially reduce the time? Such analysis helps the team to appreciate the effect of such factors and use it in future to estimations to make them far more realistic.

Any comments or views?

Reply

Avienaash Shiralige April 13, 2013 at 3:12 pm

Prabhakar,

Yeah I see your approach. You could do that. I would be careful as teams starts analysing them more than required and focus of retros shifts away, unless I see big value in doing this. Why your teams want to compare them? Points are meant for long term planning and hence they are quick and easy to do. If not we will start using points for short term planning and then we start investing more time than usual to come up with that. That defeats the purpose of sizing.

Avie

Reply

Leave a Comment

Previous post:

Next post: