I'm currently working in a team with new to agile methodology programmers and few old school peeps.

They seem to always, in planning meetings give hours/day estimates for a story. It really pisses me off and I try to tell them it means complexity/effort.

So my senior asks for one example why hours/day estimates is wrong because it seems to work here.

I can't seem to explain to them that this will mess up their velocity calculations, backlog grooming and release planning, gives an incorrect picture of teams burning capabilities to the po/pm and leads.

To be fair maybe I've not been able to explain it to them properly.

They had a question like, what do you estimate a story which would require 4-5 hours of migration. Say its migration takes 2 full days. My response is it might be a trivial script but time is not related to story point estimation. Stop comparing apples and oranges.

Could anyone help me with a few convincing examples. Because the only scrum practice which is done right in here it seems is the daily standup.

  • 1
    Classic story points stay away from being in concrete units to help a team focus on relative complexity and to find their own cadence. Given enough time and consistency those story points will become transferable to units of time. Some teams are capable of estimating straight in units of time. Good for them. I am more interested in why, as you said 'it pisses you off'. Other points of view are that one does not need to estimate beyond small big and large or what could be done within a day or two, others let go of the need to estimate all together and focus on optimising work flow.
    – Chris K
    Commented Apr 15, 2017 at 9:14
  • 1
    I suggest to you that the most important trait for the team is 'can the team as a whole self-optimise', that is does the team know where it wants to go (vision), know where they are currently (measuring) and work to improve their ability to head in the target direction ever more efficiently and effectively?
    – Chris K
    Commented Apr 15, 2017 at 9:16
  • 1
    Personally, for all but the most basic and predictable of tasks or more complex tasks that I have done often enough for them to have become simple/routine but I have not yet automated (shame on me) then estimating in hours and days works. For everything else estimating in hours and days is an illusion of predictability and control. One many cling to as a form of life line as the alternatives appear too scary to them. You may find the following interesting: scrumexpert.com/knowledge/…
    – Chris K
    Commented Apr 15, 2017 at 9:21
  • 1
    Lastly remember that people gravitate to doing what they know in the way that they have done it before. The fact that your collegues are breaking their old habits is to be celebrated, just remember that Rome was not made in a day and that they will find change less scary if they break one habit at a time rather than a big bang change of everything. Ironically studies also show that this is the fastest way to achieve complex/large change as big bang changes tend to result in big change initially and then grind slower and fail while itterative change start slower but pick up pace and momentum.
    – Chris K
    Commented Apr 15, 2017 at 9:30
  • 1
    @yudois our greatest ability to influence a team to greater heights comes not from any one technique, but our ability to create an environment conducive to learning and improving. My observation is that when I am made to feel wrong (even if I am wrong) then I lock up and become defensive. My ability to learn and adjust becomes compromised. The lesson that I learnt from this observation is to back off from pushing other people and telling them that they are wrong, but to instead ask them what they want to achieve. And then help them to deliver that to greater effect than they had hoped for.
    – Chris K
    Commented Apr 15, 2017 at 13:25

3 Answers 3


There's nothing in the Scrum Guide that says that estimation needs to be done in points. There's also nothing that says that items in the Product Backlog or Sprint Backlog must be user stories.

If your team is doing well at planning and executing their Sprints while estimating the items in the backlog in hours or days, why do you feel the need to change that?

You state that this will "mess up their velocity calculations, backlog grooming, release planning" as well as giving an incorrect picture to the Product Owner and leads regarding current status. Let's look at this one at a time.

First up, velocity calculations. Velocity is not a part of Scrum. The Scrum Guide makes no mention of the word "velocity" at all. Velocity is a common measurement, but you can still compute it with hours. Velocity is simply the amount of work completed in a specific amount of time. Often, this is Story Points per Sprint, but it doesn't have to be. It could be "hours of value added effort per Sprint" just as easily. If you are estimating Backlog Items in hours and know how many hours are in a Sprint (number of people * number of working days * working hours per day), you can divide "task hours" by "total hours in a Sprint" to get your velocity. In a perfect world, every working hour will be spent on value-added work. But that's not always true, so your velocity can be a predictor of how much time your team spends working on Backlog Items.

Second up, backlog grooming. In the Scrum Guide, this is now called "refinement" or "Product Backlog Refinement". It is simply the act of adding details, estimates, and order to the Product Backlog. The units that you use for estimation have no bearing on the act of Refinement. After Refinement, you should have Product Backlog Items that are sufficiently detailed for the Development Team to work on with an estimate attached to them and properly ordered based on the current understanding so they can be pulled into a Sprint.

Next, release planning. If you have a properly ordered Product Backlog with estimates attached to each item and you know your velocity, release planning should be easy. You should be able to pull off the top n items until the total estimate equals your velocity that deliver that in the next Sprint, accounting for any variances (people taking vacations or sick time, holidays, any kind of work events not tied to the items in the Sprint, etc.).

Finally, burn down. If you're measuring in estimated hours and are tracking hours left in the Sprint, you can still have a good idea of burn down and look at it every Daily Scrum or make it visible in your tooling. Regardless of what your estimation units are, you should be at 0 at the end of your Sprint. Burn down is just a graphical representation of how you are completing your work in your Timebox.

Now, just because you can use something other than points doesn't mean that it's necessarily a good idea. There are plenty of posts about the advantages to using points - see this question on Software Engineering Stack Exchange, this question on Project Management Stack Exchange, this post by Scrum, Inc., this post by Mountain Goat Software, and this post on Agile Buddha. However, estimating in hours is not a problem to doing Scrum, especially if it is working for your team.

Consider the principles behind the Agile Manifesto and the Scrum Values. If your team claims to be agile, they should be adhering to the principles behind the Agile Manifesto in whatever implementation works best for them. If your team is claiming to be following Scrum, they should be following the Scrum Guide and the Scrum Values regardless of their implementation of each of the activities. If your team is not following these principles, you can work to guide your team to them, but the team needs to figure out what their method of following these principles works best for them. You can share your thoughts, but not impose your will on the team.

  • Great references to The Scrum Guide! Also note that burn down charts are not a framework requirement. Commented Apr 24, 2017 at 16:28

There's no guide on scrum whether you should use story points or hours for your estimations, this is completely up the team and whatever works for them. Each team is different and whatever works for one might not work for the other.

To answer your question about the big pro about story points:

  • Story points are related to difficulty and not time, because not everyone will take the same time to finish the same task, for a Jr developer creating a simple screen might take 2 days, but for a Sr developer it might take 4 hours. The time estimation for these two resources will be different while the difficulty of the task is the same.
  • One of the bases of scrum is a self organizing team that is completely focused on completing all the tasks they committed to, as a team. One of the ways to achieve that team spirit is not assigning tasks on the sprint planning, instead letting resources take tasks when they are free. If tasks are estimated by time it might cause issues (For example the example above estimated in 4 hours and taken by the Jr developer that will take 2 days to complete it). Not assigning all tasks at the beginning of the sprint helps to avoid the usual "That was not my job, I finished all my assigned tasks"

When the tasks are easy and and the uncertainty is low, it will be hard for some to see the benefit of story points vs. concrete units like 2 days, or 4-5 hours. The benefit of using story points becomes more clear when estimating tasks that are complex and/or doing something with a degree of uncertainty.

Two short arguments that may help convince someone:

  • More often than not, estimates using concrete units are very inaccurate when the degree of complexity and/or uncertainty is high; yet these estimates in hours imply certainty.

    For example: An estimate of 75 hours seems to imply that one developer could do this in the course of two weeks, or two developers can easily do it in one week. There is no indication of complexity or uncertainty. There is also no real reason to think that the task needs to be broken down or that there is any risk of overrun.
  • Estimation processes that use Story Points, (and an abstraction like the Fibonacci series 1, 2, 3, 5, 8, 13, 20, 40, 100), tend to convey both uncertainty and complexity, in addition to effort.

    For example: There is meaning in a high number (40 story points). 40 story points implies complexity or risk in a way that 40 hours or 75 hours does not. It is also much easier to immediately see and indicate the difference between a large task that is relatively well defined (13 points) and much more uncertain ones (40 points), that may indicate that the customer should be prepared for a delay or complication.

Also important: The P.O. or Scrum master cannot pre-define the meaning of a particular story point valuation. The meaning of story point valuations will be unique to each team. A 13-story-point-valuation will only mean something to a particular team after they have played a bit of planning-poker together, and after they have a few baseline stories and sprints from which to glean insights into the accuracy of their estimates.

  • I would argue any team, using a baseline story of one point, should never have a story greater than 13 points. It's completely and grossly abusing story points to say that they have a story that is 40 times more complex or even 100 times more complex than their baseline. If your stories are not 13 points or less than there is no benefit to using story points. It is just assigning arbitrary numbers to figments of the teams imagination. Commented Apr 23, 2017 at 18:16
  • Adjust according to your baseline story value but 13 times the baseline should be the maximum before a story requires splitting down and anything over 13 x Baseline should be rejected in Sprint Planning. Commented Apr 23, 2017 at 18:17

Your Answer

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