Why are Story Points of a story not equivalent to days/hours in estimation. In Scrum [Agile]

Question

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.

Answer 1

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.

Answer 2

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"

Answer 3

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.