Why do we use Story Points for Estimating?

Great article.

"If you ask two developers to estimate the same task, you’ll get two different answers."

This is true and we should also point out that the problem isn't only with multiple team members.

You can get different answers from the same developer over time.

Effort * Business Conditions * Technical Ability of Team * Team capacity = Time

Therefore, you will also get different answers from a single developer if business conditions, technical ability, or team capacity changes.

We use story points because estimates ultimately do not matter, so we should do everything we can to reduce their criticality and the amount of time we waste on them. If we could get away without even estimating, that would even be better.

People argue that the team story-pointing generates discussion that leads to a better understanding of each story. A story that everybody instantly agrees is a "5" generates no discussion, yet there could still be a lack of consensus on what the story is really about.

Instead of coming to a number for each story, breaking each story down into thin vertical slices of approximately the same size would accomplish an even better understanding of each story and would lead to lots of other goodness which assigning a number does not.

If you said that slicing stories into however many 1-point stories it entails is just another form of estimation, I would have to concede the point, and then recommend that as the way to do estimates.

Hi, While in a backlog refinement meeting, the story points suggested by different development team members 2,3,5 etc - Is it based on a member having a specific skill such as dev, qa ? For example, John raised his hand for 5 - and is it dev only not testing ? Thanks

Dear All,

I am facing the same problem, that how we can regulate the Story Point estimation to properly manage our team performance.

May be i am wrong but some how i https://uploads.disquscdn.c... have prepared a mechanism to overcome the problem. please provide your remarks over it.

https://scontent.fsdv1-1.fn...

@Steven Gordon - if estimates do not matter, then why story point should matter? Your rationale is that estimates is useless because two developers will provide two different effort estimates for the exact same specification - this rationale is pointless to justify that story points is the savior here. I feel that your argument does not have much credit. Two developers also can and will give 2 very different story points for the exact same specification - expert developer can assign 5 story point whereas novice developer can assign 13. I am asking you to present few concrete examples of how story points resolves the challenge. One single story - use both 'story Point' and 'effort in Hours' as side-by-site comparison. Show the accuracy and benefits of using story point over effort in time. A concept is best grasped when explained with solid examples.

First off, I would say that if this works for you then roll with it. I'm not a purist when it comes to Scrum, Agile, or almost anything else in my life. We deviate from Scrum rules and customize our practices to fit our teams. Please take my points below as conversation starters and things to consider rather than criticism. The thing that jumps out at me is that you're mapping points to hours. I always advise against doing that. If you map points to hours then you might as well just estimate in hours and skip the conversation. We estimate in points in order to be able to approximate what we should be able to complete in a Sprint and then be able to extrapolate our velocity so that we can ballpark how long work spanning Sprints should take. However, the most important reason for using points is to be able to track if our velocity improves as we make refinements to our process and mature our Agile practice. The reason I advise against tying points to hours is because by doing that you're essentially estimating in hours and the only way for our velocity to improve is to work more hours. By using straight points we're divorcing estimates from hours and forcing ourselves to think of the work in terms of complexity, risk, and effort. It take time for a team to get good at estimating in pure points, but it's an effort that will bear fruit and will prove itself worth the investment.

I like this answer - Story Points rather than hourly estimates enable us to do what we want to do as a team; continuously improve and have a metric to help us. Story Points are less useful if someone is wanting the team to plan out what we will be doing when - which is not what we want to be doing as a team - it's what someone outside the team is hassling us for. If they want to take our velocity and use it to turn Story Points into hours then good luck to them.

a story is complete when its ready for deployement.. i.e. Dev + QA done.. to achieve this, story has to factor in both Dev & QA efforts to estimate the story points.

I'm still looking for an article which mention the calibration issue. The first estimated story, how do you decide if t's 1, 20 or 100 story points? I understand relativity but what about the first estimation?

How do you resolve the story point value if Dev scores a story as 5 points and QA scores the same story as 2 points? Do you take the highest of the two?

#NoEstimates

Take both. Dev says how much effort to create the solution. QA says how much effort to test the solution.

It is more important to have a well defined story that it is to assign any estimate of any kind to it.

Story points are an indication of how much work the team as a whole can get done. Stories should be estimated collaboratively by the team and never by a single developer (or even worse, by a manager, Product Owner, or Scrum Master). One advantage of story point estimation is that it stimulates discussion during the planning poker process. For example, if one member estimates a 5 and another member estimates a 13, they will each need to give justification for their estimates based on his/her understanding of the story. The ensuing discussion should help them converge on a common understanding of what is involved in getting the story to completion.

Also, keep in mind that a story point is supposed to be a relative measure of size compared to other stories, not a reflection of how much effort will be required by a single developer. Your example of an expert developer assigning 5 points and a novice developer assigning 13 points seems to indicate a misunderstanding of this concept.

Teams should never try to estimate hours directly. Humans, and software developers in particular, consistently tend to underestimate the effort required to complete a task or project. This is called optimism bias and is a major factor in explaining why projects tend to be late and over budget. The reason story points are always based on relative estimates is to remove this bias and base future estimates on relative size/complexity compared to historical data. That's also why it's a good idea to keep a set of "reference stories" on hand to avoid drift over time.

Finally, it's important to understand that story pointing is not a panacea. Forecasting is only as good as the estimates it is based on. There are times when story points may not be appropriate at all. For example, a team doing maintenance work on a product it is unfamiliar with may be better off just using throughput (item counts) because the team doesn't know enough to estimate accurately.

For the first estimate, the team should choose a couple of stories of different sizes, and assign Story Points to them. These are known as the base line estimates, and should be used for future stories to estimate relative to these. I have found it useful in the past to ensure these base line stories have a good coverage of the end to end technical stack. This allows for comparing like for like stories. E.g. if your baseline story is to "Create an API for xxx", and you are trying to estimate a story for "Perform database upgrade", it is very difficult to get an accurate story point estimate, as they are not very comparable stories.

A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“ And what is effort? Effort to me are hours.

Ok, I have 5 histories that holds a value of 3 story points, 2 with a value of 5 and 4 histories with a value of eight. It would be pretty much the same as 5 small stories, 2 medium histories and 4 large histories. My assumption is that in the same team these 5 histories will take a similar effort (ie. 3-5 hours), medium will take more effort than small and large will take less effort than medium. If small histories takes more, a plausible reason could be that they were not small but medium. But my point here that effort to me are hours, or what else?

If you look up the linked discussion to Mike Cohn on Storypoints, you will see that yes, there is indeed a link (of course) between story points/effort and time, but the whole point is that it's premature to do absolute time estimates on a detailed task level due to the high variance in developer output. Agreeing on the relative difference in effort on the other hand has smaller variance. What you care about from the outside is the performance of the team, and by knowing that they produce 45 story points on average each week (after some iterations) you can get pretty good estimates on what the team is able to produce in the next months. But using hours per task is a bit fruitless as that varies so much per developer, while the aggregated team output does not.

Great article, thank you! Our team has trouble estimating. Back end and front end estimate in completely different ways, meaning that this is difficult to have common tickets between the 2 (for example for bugs, or hiring). Even FE team member don't estimate the same way, as usually our junior team member gets more story points done than the more senior one. Should everyone have the same base? Otherwise, does it mean we will always need to split estimation between what FE deliver and BE deliver?

@disqus_NnpD1M8DX1:disqus This video may help you with first estimation
https://www.youtube.com/wat...

Mr. Michael is true.. Story point concept works for only like stories.

Story points are worthless. You need to convert to hours anyway for planning. It only confusing people. A tech lead should do prelim design and estimating of tasks....if someone on the team takes longer (like a junior level developer) that needs to be taken into out (in other words they aren't 85% available each sprint, rather 75%).

might as well use T-shirt sizing. S, M, L, etc. They are also need converting to real world hours. I can't plan a sprint if you say there are 3 mediums and 1 large story to get done. But if you tell me there are X amount of stories for Y hours and Z hours are available, then, then we can plan.

on my projects, time is a unit of money. Arbitrary units of measure like story points or t shirt sizing don't help because they all have to be converted to time anyway

T-shirt is much worse for long or short term planning. After all, how much larger than an S is an L. Pizza sizing at least provides a more useful analogy, where an M is about twice as much area as an S and an L is twice as large as an M at most pizza chains ;-} .

Thin vertical slicing is ideal for sprint planning. As long as slices are tackled in priority order, the best outcome is achieved without perfect detailed hourly planning (and all the time wasted trying to do it). Slicing also makes it easier to put off the lowest priority few slices at the end of the sprint instead of dealing with an incomplete larger story.

Actually, they do not need to be converted. Just use priorities and the story points to steer development and trust that the team is doing their best. The amount of time and grief saved by avoiding detailed planning, accounting and management second-guessing gains much more than is lost with occasional inefficiencies.

Story points were always tied to time. Someone will ask "are story points related to time" and the scrum master will say "no". Developer will say "3 story points". The Scrum Master will turn around and say "Okay, so that will take 3 days to complete...."

This is easily one of the worst articles I have ever read in my life.

"For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour."

Umm the same goes for Story Points.

So many other issues in the article - especially how it's just beating around the bush. But stating one should be enough.

Story points aren't worthless. If we work on the assumption that estimates in time have a tendency to be inaccurate but Story Points weigh stories against each other it only creates a problem if you want to impose time or cost constraints on your delivery. One problem with the whole attitude businesses have to Agile is that they assume that it will be cheaper than more traditional project methodologies. It may well produce results that are quicker into testing and quicker to live software but that doesn't mean it is cheaper. Assume that you have four gradings for Story Points. So a Story will be graded Small, Medium, Large or Huge. Huge ones should be broken down. Then you just need to settle on the others. Over a period of time your Scrum Master and Product Owner should be able to monitor effort expended to see what the variation on the delivered stories looked like and they will be able to work out how to align time spent against the story points for the project in question but this will most certainly vary massively between projects and maybe even between sprints in the same project.

Without the prior, the latter is just a guess anyway

XXXXL always draws a sharp intake of breath :-)

Story points continue to confuse everything. Academically it may make sense, but when you have teams that constantly change members (which is more often the case than not), story points don't help you. Having to continuously try to figure out what story points mean in a business context is exhausting and a complete waste of time. One of the biggest problems with agile development (especially SAFe) is that it expects everyone to learn a new language with new terms and syntax that isn't easy to understand and requires constant explanation. Frustrating.

Someone should do an A/B test of story points against a dartboard, like the wall street journal did with stock market advisors. Usually the dartboard won.

it's not a frog but a toad

For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell we can. Because we did that for hundreds of years and built Pyramids, Eiffel tower, space shuttle and google.com

broken link fyi on: why Story Points are better than hours - http://scrum.jeffsutherland...

My issue with the argument that story points provide insight that time does not is that time is still a project constraint, and is still a function of velocity. If a project owner asks "what can we have by August 1st?", doesn't all the estimating and sprints come down to how much work we're going to do and how much functionality are we going to be able to develop in the time between now and then?

And then, very often, time is a function of cost, in those shops wherein work hours are tracked to produce the AC component of EVM. And since points = "effort", points absolutely do affect how many hours are being consumed developing the story.

Points/time, tomayto-tomahto. When it was first devised, sure, it was new and shiny and felt all cutting-edge. Terrific — but hey, you can call a rose whatever you want, it smells the same.

I'm sorry, but the logic in the story point argument is flawed. First, you assume that story points are estimated for an entire backlog, which for a project of any significant size can be a monumental effort, but for the sake of argument let's say this is executed. You also make the presumption that for a given team, each developer completes a task of a given complexity in a given amount of time, even if that time is different for different developers. If this were true, then over time, velocity becomes predictive as for the entire team a given level of complexity can be executed. This presumption is inherently flawed as it does not take the skill set and abilities of the developers into account relative to the task itself. The same developer may be able to complete tasks of varying complexity in varying time based on his skill set and experience.

The size of ANY task is related to the skill and experience of the person executing, regardless of whether you are comparing it to other stories or not or the unit you are using for estimation. The complexity is always based on the skill and experience of the person executing. As an example, I am very familiar with Kubernetes and can quickly develop helm charts for my Kubernetes deployments, but for less experienced developers this task takes significantly longer. These less experienced developers will never become experienced developers unless they are given the opportunity to execute, so they will be assigned these user stories in some sprints. Developing user interfaces on the other hand tends to take me longer as my color blindness means I am constantly comparing color codes against my specification to make sure I have gotten it correct (plus, I just plain suck at it), but there are occasions where I am the person developing the UI. Applying your logic to this example, the story points for these user stories would be the same regardless of who is assigned the task.

This means that from sprint to sprint, velocity will vary based on what tasks different developers are assigned. Also, regardless of the unit of measure, if you want to complete your user stories in a given sprint, time has to be taken into account at some point as you only have x hours to complete your tasks and it is undesirable for a user story to span more than one sprint.

In a very large team, you may have the luxury of specializing your developers and assigning tasks to those who can complete in the most expedient fashion, but for most teams I would assert that this is not the case, making story points of limited use as a predictive analytics tool.

Story points are a disaster for Agile, the problem is non-Agile project managers leap on story points as a way of estimating delivery dates by trying to equate story points with time, it that were true there would be no need for story points at all and we could all go back to estimating time and start up the Gant charts again (project will finish in 6 months, two weeks, 3 days and 4 hours - according to the Gant chart).
Also management become fixated on how many story points have you done this sprint ? not, what is the functionality delivered.
The reason we need Agile is because humans can NOT estimate accurately beyond a day how long things will take, if you don't believe me read the book 'Thinking fast and Slow' by Daniel Kahnman, particulary the section called 'Planning fallacy'.

Allen Holub gives an excellent talk on this subject. https://www.youtube.com/watch?app=desktop&v=QVBlnCTu9Ms
I also broke down the issues with story points long form recently in Story Points are Pointless, Measure Queues. Many of the points raised by this very article agree with it too. They don't work mathematically and the time we invest trying to make them matter is generally wasted. There are better ways, that Allen talks about above too.

https://www.brightball.com/articles/story-points-are-pointless-measure-queues

The variations are actually not a fundamental problem at all. The problem is that you cannot estimate even your own effort accurately under the best of the circumstances

You need to understand that the people developing these new methods were trying to reinvent the wheel.

"Well, in a nutshell, because your hour is not the same as my hour". It absolutely is the same. What is not the same is what you do with it. The story points are meant to be an answer to the question of how much time is required to complete the task. Why reinvent a wheel? Because it is cool