Why use both story points and hours?

Question

I'm a new scrum master for a team that is using story point estimation and hours. We do story points first during grooming and then hours during planning.

I always thought of story points as being primarily for the project manager, and hours being for the engineers (this was simply the way we had been doing things). A coworker and fellow engineer asked why we are using both.

While I read articles such as: Don’t Equate Story Points to Hours, which explains why you shouldn't use story points to hours even though they are related Or Is there any published research about story points vs time estimation? which explain that story points are more accurate for estimation.

I fail to see much written about using both of them. We estimate stories by story points which gives us a broad sense, and then we drill down how long each task will be and use the story points and hours to give ourselves an estimate. I'm beginning to wonder however if my coworker is on to something.

Is using Story Points and hours a thing? Is there any advice for or against it? I recognize it probably takes an additional 2 hours to do both (multiplied by every member of the team) and it costs a lot.

Why use both? Anyone have any experiences with this?

Answer 1

Story Points Estimation and Hours Estimation have different purposes.

We use Story Points during Product Backlog Refinement.

Story Points are good for high-level planning.

• When we make an estimation in Story Points we talk about the productivity of the whole team. During high-level planning, only the productivity of the whole team is what matters.

• Story Points Estimation is a relative measurement. It's very convenient for high-level planning. If the team increases its productivity (by using CI, for example), then the team will just forecast more SP in the next Sprint. In the case of hours estimation, the team should re-estimate (and reduce needed hours) the whole Product Backlog.

We use Hours during Sprint Planning.

Hours are good for low-level planning.

• When we make an estimation in hours we talk about the productivity of concrete Developers. It's impossible to use SP for planning tasks of specific Developers, because (as I said before) SP are for relative measuring. One developer can implement 1 SP in 1 hour, another can implement it in 2 hours.

• Hours Estimation is absolute measurement. It's very convenient for low-level planning. You always have 160 working hours in a month, and the productivity of the team cannot greatly increase or decrease during this short period.

So, that's why we estimate the Product Backlog Items in Story Points and Tasks (on which we decompose BPIs) in hours.

Answer 2

Story points are too fuzzy for tactical Sprint Planning

Is using Story Points and hours a thing? Is there any advice for or against it? Why use both? Anyone have any experiences with this?

Let us say your team's average velocity (over the last 3 or more sprints) is 30 story points. Let us say it has fluctuated between 27 and 32. For the next sprint do you, as a team, forecast 30 points (the average), 27 points (conservative) or 32 points (optimistic)? There is not an objective way you can determine that. You have to factor in all the break-out tasks and team members' vacations, holidays and so on.

In any case during Sprint Planning you are doing more detailed planning by drilling down into how you are going to implement the story by identifying the individual tasks. Estimating hours should not be too much extra effort. It helps you to put your Sprint forecast of stories on a much firmer footing.

I fail to see much written about using both of them.

Mike Cohn's analogy of a basketball team is probably easier to grasp: Suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.” This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

You can also read his more recent article on this same topic:

Why Sprints Should Be Planned with Hours, Not Points

Both articles have good comment threads with more clarifications from Mike.

Answer 3

There are two reasons I've seen groups use both story points and hours:

1) Someone just can't let go. Usually that someone is a PM or manager and they can't quite bring themselves to give up the specificity of hours, regardless of how accurate they may or may not be. This is, of course, not a good reason to do it, in fact it's a very bad one, but better to call a spade a spade than lie to yourself about it.

2) I've seen teams estimate stories with points and then estimate tasks in hours as a sort of check against their previous estimate. Doing this can actually trigger conversations about what goes into fulfilling a story that the team might not be having otherwise, especially if they've been doing hours estimation for years. For example, one team member might say "that'll take me 2 hours to complete" and another says "is that with or without the time it will take you to provision the new server it goes on?" and the first person responds "Wait, we need a new server for this?!" and so on. Good conversation and it's adding value. That said, I'd have a goal to get away from those hours estimates as soon as the team is comfortable having those discussions without the hours for two reasons:

1) You still have all the same problem with hours you always have. Humans are still terrible at estimating time, managers will still try to do strange estimate-to-actual evaluations, and everyone will have a natural inclination to hold the team to fulfilling their hours instead of delivering value.

2) Adding estimates like this anchors tasks. It creates an aversion to modifying the tasks, removing them, or adding new tasks. In my experience, tasks should be a tool for the team to organize their work in whatever way helps them most and should not be a measuring stick.

Answer 4

Story points are used as a relative complexity measure and over time establish a team velocity - an average amount of work a stable scrum team can commit to during a fixed iteration. IMO story point estimation is a cornerstone scrum practice that helps empower the team to manage and own their iteration commitments.

Hour estimates are used to drive discussion around individual tasks needed to complete a story. Do you need tasks? It depends on the maturity of the team. Immature teams can benefit from hour estimates when they do not have great domain expertise and are unable to do relative complexity estimation with story points. Most mature teams I work with will stop hour estimating because it takes a lot of time and in the long run its harder to do accurate hour estimation vs story point estimation and velocity based planning.

Side note: I've seen all too often immature teams that rely solely on hour estimates opening themselves up to micromanagement by traditional PM's who think a team that has X hours of capacity and Y hours of task estimates will complete all their work in an iteration when X = Y.

So do you do story points, hours, or both? It depends on the team. Ask your team members if they see value in any of the estimation practices so that you understand what works, what doesn't, and in which direction(s) your team can improve.

Answer 5

Story points and time-based estimates can be used in a complimentary way in Scrum.

Story points are primarily about determining the capacity of the sprint. So you look at your team's velocity and use that as a rough prediction of the capacity for future sprints.

However, once you have loaded in stories to your story point capacity it is sometimes also useful to then do a time-based estimate. The reasons for this are:

• The time based estimating can draw out more information about the tasks. The actual practice of time-based estimating can be valuable, even if the time-based estimates are then ignored.
• Time based estimating can help the team to spot when there is an over/under commitment to one particular discipline. For example, you may realize that there is too much back-end development and not enough front-end development to match the capabilities of your team. Of course, if you have multi-discipline teams this is less of an issue.
• Sometimes the time based estimating can call in to question the capacity based on story points. I have seen teams put 40 points in a sprint, then do detailed planning and time based estimating and as a result realize that 40 points were too much.

Of course, doing both time based and story point estimating increases the time and effort the team spends on estimating. It is for the team to decide if the extra effort is worth it.

Answer 6

You estimate the story using story points during the first part of the sprint planning meeting - this gives you a quick way to determine how many stories the team can take into the sprint in fairly quick time

A lot of teams do that and that's it. But if you do the second part - and break the story up into tasks - you use hours for the tasks. The sprint burndown - then is based on the total hours of all the tasks in the sprint. The burndown can and does go up - as the estimate to complete can be go up as you understand the task better.

In summary then - You use points for the Story - and then Hours for the tasks within the story.

Answer 7

Personally I would avoid using hours as its impossible to estimate how long a task is going to take accurately. I think story points are the best way to estimate stories and I don't think you need to estimate tasks the team should do whatever it takes to complete the story.