I've been reading up a lot on the subject, and from what I can gather the following statements 'should' be true in scrum:

1) Estimate user stories in story points at the product backlog level. This allows abstraction of the estimates, and the team can estimate together without dispute - e.g. one developer may complete the story much quicker than another, but for both, the estimate is 3 story points.

2) You ideally shouldn't assign tasks during sprint planning. While it helps with indivdual accountability, it reduces team accountability

3) In sprint planning, flesh out the tasks involved for each story, and estimate these in hours.

My question is this, how can you estimate the tasks in hours, yet still not assign the task to a specific developer (points 2 and 3)? Surely the whole point of using story points is to avoid the expert developer saying it'll take 1 hour, and the junior dev saying it will take 8 hours.

If you are now estimating tasks within sprint planning in hours, how do you reach an estimate which is good for all team members of varying levels of expertise, without assigning the task to the specific dev who's estimated it?


  • 1
    You can't this is why you estimate in points
    – Ewan
    Commented Apr 26, 2019 at 12:02

3 Answers 3


The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide.

It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one of the attributes of a Product Backlog Item may be a size. However, there are many ways to size Product Backlog Items, and a size doesn't even need to be a numerical value. The purpose of sizing or estimating is to enable the Product Owner to understand how much effort is likely to be required to complete work to properly order the Product Backlog and for the Developers to be able to effectively plan a Sprint by determining what Product Backlog Items can likely be completed in an iteration.

Scrum is silent on if the Developers should be assigning work or not during the Sprint Planning. The Scrum Team is self-organizing and self-managing, and the Scrum Guide does say that it is solely up to the Developmers to determine what they can achieve over the course of the Sprint and how it is done. The requirement is that, by the end of Sprint Planning, the team has done enough work to determine which Product Backlog Items they can likely achieve by the end of the Sprint timebox. Some teams prefer to assign out all of the work, at least tentatively. Other teams prefer to pull the work in as the Sprint progresses. Both are valid, and both have tradeoffs.

In Sprint Planning, you don't need to break down every single Product Backlog Item. You need to do sufficient breakdown of the work to ensure that you can take a subset of the Product Backlog and forecast that you can achieve the Sprint Goal. This work can be done throughout refinement activities that occur (there is no specific Scrum event for refinement) as well as at Sprint Planning. The act of placing estimates on Product Backlog Items is an outcome of refinement, which may be estimating in points, hours, or even no value and simply ensuring a nearly uniform size of Product Backlog Items.

Now, moving on to estimates. There are some good practices for estimating work in software development. One of those practices is not assuming that the work will be done by any particular person. Different people take different amounts of time to achieve something, simply based on their knowledge and the set of skills needed to do the work - not everyone is equal. You shouldn't be estimating work to be done by the expert on the team, since that person may not be the one doing the work. On the other hand, estimating as if the least skilled person is going to do the work would result in overestimating everything. So you need something in the middle. Techniques such as Wideband Delphi and Planning Poker are designed to help with this.

This is also one of the reasons why people tend to avoid estimating in hours. There are two considerations here. First, complexity is not likely to change based on who is doing the work. The work is equally complex, but some people have existing knowledge and skills that allow them to cut through some of the complexity. Second, if you estimate at the team level, complexity is also considering the team's effort. More complex stuff is more likely to include pair programming, more intensive peer reviews, more testing, and so on.

So, my recommendation is two-fold:

  • Use consensus-based estimation techniques and risk management to determine what the right estimate is. Find something between the mid-point and the highest estimate, based on the level of risk that you are willing to accept in the estimate.
  • Consider moving away from time-based estimates toward complexity-based estimates. Or, as an alternative, extremely small units of work that are all roughly equally sized.

The official Scrum answer is "Estimate complexity not time and use Story Points"

However, on a practical note I would say estimation is not something you want to get hung up on. There are a couple of main objectives scrum is trying to achieve which impact estimation.

  1. You can measure progress towards the story in terms of completed tasks.

    This means that the tasks have to take around a day to do. Because you have your daily scrum each day. If a task isn't done by the second daily scrum you know there is a problem

  2. You can measure progress towards project completion in terms of completed stories.

    This means that stories must take less than one sprint to complete. Because at the end of each sprint you demo completed stories. If the story isn't done by the second sprint demo you know there is a problem

So as long as your story get broken up into tasks that take less than a day and any stories longer than 1 sprint are broken down further you are good.

If you have some super fast/slow devs this normally isn't a problem because you will have lots of very small tasks that that the fastest dev an hour or so to do and the slowest dev a day or so.

The rate of progress averages out, as long as you can report the progress

  • That is not really true. The official Scrum (Scrum guide) does not use the term "story points" and nor does it prescribe complexity estimations. It only says that the development team should estimate the product backlog items. Also, the official Scrum never suggested user stories.
    – John V
    Commented Jan 23, 2020 at 11:23
  • I guess we are arguing about the definition of official then. mountain goat software advocates story points. The scrum guide is too wishy washy to be of practical use
    – Ewan
    Commented Jan 23, 2020 at 11:37
  • 1
    Well, the original Scrum is defined by the Scrum guide and its power is in the fact that it is just a framework, not prescribing to use this or that. Unfortunately, many companies started to create artificial layers of rules so they can sell it to companies. I agree that typically you need to choose some practices but it is not fair to present some as official when, in fact, anything that complies to the Scrun guide guidelines works ;)
    – John V
    Commented Jan 24, 2020 at 11:49
  • Its pretty easy to rewrite history here. "original" scrum was nothing like the thing people do today
    – Ewan
    Commented Jan 24, 2020 at 12:01

In sprint planning, flesh out the tasks involved for each story, and estimate these in hours.

I've never split stories into tasks or estimated something in hours. You can do Scrum without any of that if your stories are well defined and small enough.

Instead of trying to do the impossible (estimate in hours without knowing who will do it) just improve your user stories so you don't need tasks at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.