top of page

Why do we use both Story-Points and Hours estimations in Agile?

Authored by - Vinay C






This is a contentious question and I have posed it to many Agile practitioners; the answers and opinions often vary from person to person.  I have made a candid attempt to decipher this. Your views and comments are greatly appreciated. 


It is important to understand that we never estimate a story in terms of hours, and we never estimate a task in terms of story points.  Hierarchically speaking, a story is at a higher level and consists of multiple tasks underneath. A story always comes first, and tasks come next. The effort needed to complete a story is the summation of all the hours entered against its tasks (children). This total number of hours is then represented as story-points at the story level. 


Why do we need these two units of measurement? Why can’t we just use story points or just hours? 


Let’s suppose you ask someone, “Can you tell me the distance between Delhi and Mumbai?” The answer could be 1,400 km OR it could be 20 hours. So you have two answers, both are correct in their own ways, and both are relevant to what you just asked. 


An important point to note: while you can improve upon the 20 hours of driving time and bring it down to, let’s say, 19 hrs and 30 mins, you cannot change or improve upon the distance – it will always be 1,400 kms. 


Also, note that, 20 hours could become 18 hours if you ask a private car owner; 25 hours if you ask a bike rider; 30 hours if you ask a cab driver. All these answers are valid and truthful because they reflect the time THEY need. Add rains and road conditions, and the number might differ even more. 


The hours for each task(s) are added up and converted into story points and logged against that story.  


A story is then classified as a Simple (S), Medium (M), or Complex (C) story, based on its story points (SPs).  

For instance: 

  • A simple story usually will be: 1–3 SPs 

  • Medium story usually will be: 5–8 SPs 

  • A complex story usually will be: 8+ SPs 

 -

This categorization is defined by the Scrum Master of each team and is specific to that team. It is not applicable to other Scrum teams. 

 

What is the value of a story point in terms of hours? 

The answer to this varies from one scrum team to another. The less hours you take to  

complete a story, the more mature and efficient your team is. 

 

Where does my analogy of time and distance fit in, here? 

 

Distance is the story points.  

Time is the time taken to complete a task. 

 

Let’s consider a simple story which is of 3 story points for our discussion. 

  

Considering 6 hours as the benchmark for completion of a story point worth of work, our 

3-story point story may take 14,15,16,17 or 18 hours. (1 story point is 6 hours; 3 story 

points should be 18 hours, but if an experienced and a capable resource is working on it,  

they may just take 15 hours, but the scrum team will still consider it as a 3 SPs story, 

because it is within the range of 1-3 story points. 

 

This range is where Scrum allows you to build-in that automatic buffer or cushion for a 

young, relatively inexperienced developer. He might probably be riding his bike 

which is slower and less safe compared to a car and it is raining as well. So, he must slow 

down. But an experienced person might just be able to zip through. 

 

This is how Scrum allows us to accommodate a novice and an expert in your team, thus 

allowing you to have the appropriate resource mix (RM). An ideal RM will keep 

 your resource costs in check. If all your team members are experts, then obviously 

 your team can deliver more, in less time, but your costs will skyrocket.  

 

Why use Story Points estimation? 

 

They encourage team-based, experience-based estimation.  

  • An experienced resource’s effort estimate will likely be lower, while a junior member might estimate more time. 

  • They avoid the compulsion to provide exact time estimates. 

  • They help standardize velocity across sprints. 

  • Once stories are committed to a sprint, teams may break them down into tasks and estimate each in hours. 


Why use Hours estimation? 


  • To distribute the workload and plan for each day. 

  • To ensure stories fit within the sprint timeline. 

  • To help junior members understand estimation and fine-tune their skills as the team progresses. 

  • For tracking a story as it moves from one status to another on the task tracking board. 


Why Use both? 

Story Points 

Hours 

Help in long-term planning and forecasting 

Help in short-term execution 

Based on relative sizing 

Based on actual effort 

Useful for tracking velocity 

Useful for tracking daily progress 

Encourage team discussion and alignment 

Help with individual task assignment 

 

 
 
 

Comments


bottom of page