Story point estimtaes Vs Tasks hour estimate

Last post 05:46 am July 3, 2019
by vishal Rajadhyaksha
6 replies
02:44 pm May 20, 2018

Hi, I am working in a project where the scrum master wants to estimate both stories, and tasks in points, so effort estimates not hours estimates, while I am convincing him that is better to estimate tasks in hours? For me it depends on the person who works on the task, and it is easily for tracking , but means while I am confused why I estimate story in points and tasks in different hours (how can they be related) Can I know which technique should be used with tasks, and why?

07:13 pm May 20, 2018

What method of estimation do the Development Team think they ought to use, which would allow them to forecast their Sprint Backlog most effectively?

Generally speaking, if stories and tasks are used, tasks can be sized in hours because they are sufficiently fine-grained to support reasonably accurate time-based estimation.

However, instead of trying to prescribe a certain technique, it would be a much better use of Scrum if the team inspected and adapted their own process. A Scrum Master should encourage them to do so.

04:10 am May 24, 2018

Hi Rasha, 

I had such case about 2 years ago when the SM of one of the team (at that time I was a member of Dev Team) decided to implement Fibonacci numbers instead of hours. Maybe, in general, it is a good idea but for us, it was much more convenient to estimate in real hours instead of Fibonacci numbers. So, after 2 Sprints we decided to return to hours. In my mind, there should such method for estimating which is more preferable for the Dev Team.

P.S.  By the way - now we use Fibonacci numbers

04:55 am May 24, 2018

Pure coincidence I had this question yesterday and spent some minutes with the team explaining my humble opinion on the topic.

First:  I've been with this team for just 3x 2-week sprints; they are 8 months old and were up to Sprint 21 from memory.

They had never been taught Capacity Driven Sprint Planning;  on their first Sprint Planning with me they were visibly stunned.  I was taken aback at their surprised reactions.  "That is the first time we've finished Sprint Planning with no stress and arguments!"  "Huh?" - I was really surprised.  "We never finish on time and we always argue!  And this is the first time we've both finished on time, it was a relaxed meeting and we finished on time."

Although I wasn't around before April with this team, I believe they were being forced into a push-type velocity driven sprint planning technique;  management had probably gotten hold of velocity and perhaps they were being asked questions like "How much velocity do you have left?"

Capacity Driven Sprint Planning is a technique to ensure that no single team member bites off more than they can chew and therefore crashes the sprint.  I accept that "crashes" the sprint is a harsh term - it's all about learning, right?  There is no such thing as a failed sprint, only learning opportunities.

Capacity Driven Sprint Planning goes something like this:

  • Approx 10% of a Sprint's time is in the events
  • Upto 10% of a Sprint's time is future-looking, Lean's Just-In-Time Analysis, Backlog Refinement
  • That leave's approx 80% of the 80-hours in a typical 2-week Sprint to work on the pulled-in-by-the-team / selected Product Backlog Items.  Call it 60 hours for round numbers.  Work expands as you get into the detail anyway
  • Once the Topic 1 of Clarification and Conditions of Satisfaction / Acceptance Criteria are out of the way and the team understand what the customer wants and under what conditions they'd be satisfied it is done, the team can then start the conversation of "Tasking out" - not 100% of the tasks because we know that work expands as we get into the detail - but just enough to kick off a conversation, discuss, collaborate (agile manifesto value statements #1 and #3) and be able to forecast whether they believe they could deliver this item.
  • As each team member identifies tasks and volunteers for that task - a Product Backlog Item is given to a team, never an individual;  Tasks are what Individual Team Members work on so that collectively Team Members deliver the Product Backlog Item as a team to the satisfaction of the Product Owner - they chip away at their hours.  E.g. if they take on a task that is roughly 8 hours then they use pen and pad to reduce their original 60 hours to 60-8=52.
  • And this cycle of repeatedly chipping away at their running total of hours remaining continues.
  • It's purpose is to assist Team Members from ensuring they don't take on a pressured, stressful workload.
  • You can tweak this technique to assume 6 hours in a typical contract's 8-hour day (or 7, depending on your flavour).


Once the Task Time in Hours has been used;  throw it away.  It's served it's purpose.

It has nothing to do with Story Points (relative size of effort weighted for complexity, uncertainty and risk) or Ideal Days (an attempt to say "If circumstances are ideal e.g. all Risks, Assumptions, Issues and Dependencies are mitigated or do not exist, so an Ideal situation, how long in days would this team take to do this item to the satisfaction of the customer?").   Individual Team Members' Task Time in Hours is used to assist in Planning to ensure workloads are not compromised and factors in Public Holidays, Personal Holidays, any Corporate Overhead such as Mandatory HR Training; Ideal Days is one long-term-planning / collaborative conversation provoking Estimation Technique.

If that's helpful?

I've had huge success with this over the years.

02:00 pm May 24, 2018

Hi Rasha,

I've always found estimating the stories in points and tasks in hours. SM probably wants to use story points because he/she wants to see and monitor the velocity of the team. If you use only hours, this won't be possible as the total capacity of the team will always seem to be constant which would be equal to number of hours in your sprint length. 

08:39 am July 2, 2019

Hi everyone,

Let me share our way of doing Sprint Planning.

So basically after the team knows the "wish"of our PO in regards to sprint scope,  they go into planning 2 where they breakdown the UserStories into subtasks and they estimate each subtask in time using hours.

In the beginning of planning 2 we start calculating the capacity of the team for the sprint due to holidays, trainings, meetings, or maybe new joiners, and then we see how many hours do we actually have for sprint scope work. Of course we remove from the capacity the time spent in scrum events. 

 After capacity forecast we get a rough idea how much time we have in the upcoming sprint for actual work.

After that when the teams are finishing the time estimation we make a check vs the capacity and what fits into the sprint  becomes the forecast and what does not fit into the sprint will fall into the product backlog.

Of course the teams also use their gut feeling  when forcasting taking into account team velocity and their feeling and not only capacity check vs subtasks estimates

beside that we estimate user stories in story points

so far it worked quite good :)

now we want to try to see how it feels to just use the team's velocity without estimating the subtasks in time

hope this helps bringing some clarity



05:46 am July 3, 2019

now we want to try to see how it feels to just use the team's velocity without estimating the subtasks in time

We are doing just as you have mentioned above. We know our velocity is 15 story points(When all developers are present for all 10 days of sprint) . We estimate stories like below-:

1 story point= Simple

2 story points= Medium complexity

3 story points= High complexity

5 story points= Complex but can be completed in 1 sprint

8 story points= So complex or big that it needs to be divided and cannot be taken in a sprint


How we decide if story is of medium or high complexity ? It's a collective decision of development team. So, basically if you want to climb a rope of 3 meter and you ask complexity of this task to 10 people after giving above chart (1=simiple, 2=medium), I am sure out of 10 , 60% will say 1  and remaining will say medium. Noone will say High. Similarly, while estimating story, majority of developers will give good (Close to reality) estimation.

This way we select 15 story points.  One thing I would like to add is we calculate capacity in terms of Percentage and not in terms of hours. So, if our capacity is 80% only, we select 80% of 15 story points= 12 story points only.