Check out this video you might like. I cover this in a short video: What are Story Points? Close What are Story Points? Transcript Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assigned are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story is that assigned to one. It should also be two-thirds of a story that is estimated as three story points. Instead of assigning one, two, and three, that team could instead have assigned 100, 200, 300, or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers. Because storypoints represent the effort to develop a Story, a team's estimate must include everything that can affect the Effort. That could include the amount of work to do, the complexity of the work, any risk or uncertainty in doing the works. When estimating with story points, be sure to consider each of these factors. Let's see how each impacts the effort estimate given by storypoints. First, amount work. Certainly, if there's more to of something, estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page, has 100 fields, also to be simply filled with a bit of text. Despite having more fields the second pages no more complex. There are no interactions among the fields and each is nothing more than a bed of texts. there's no additional risk on the 2nd page. the only difference between these two pages is that there is more to do on the second page. This means the 2nd page should be given more story points. It probably doesn't get 100 times more points, even though there are 100x as many fields. There are, after all, economies of scale, and maybe making the Second Page is only 2 or 3 or 10 times as much effort as the First Page. Let's look at risk and uncertainty. The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item. If a team is asked to estimate a Product Backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate. if implementing a feature involves changing some old brittle code that has no automated tests in place, That risk should reflected into the Estimate. Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a webpage with 100 trivial text fields with no interactions between them. Now think about another webpage also with a hundred fields. But some are date fields, with calendar widgets that pop up. Some are formatted text field like phone numbers or social security numbers. Other fields do check some validations, as with credit card numbers, This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the users enters an American Express card a four- digit CVT field shown Even though there are still 100 fields on this screen, these fields are harder to implement. They're more complex. they'll take more time. There's more chance the developer makes a mistake and must back up and correct it. This additional complexity should be reflected in the estimate provided. It may seem impossible to combine multiple factors into one number and provide that as an estimate. It's possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item. That effort is a function of the volume of work, how much there is to do. But it is also a funtion of risk and uncertainty of a product backlog item. Depending on how an uncertainty is resolved or whether a risk hits, a Product Backlog item may take more effort to complete. And so, team members consider the risk of a problem occurring and the impact if the risks does occur. That means that a risk that is likely to occur, and will take a lot of effort to address if it does, will be estimated as more story points than an item that's neither likely nor time consuming to adress. But story points are also a function of the complexity of their work to be done. Work that is complex will require more thinking, may require trial and error experimentation, perhaps more back and forth with a customer, maybe take longer to validate, and may need more time to correct mistakes. This means complex work is given a larger estimate. Each of these factors, volume of work, risk, uncertainty, and complexity, is combined based on the impact each has on their likely effort to complete a product backlog item. Finally, when estimating story points, the team needs to include all work to fully implement an idea. A story point estimate must include everything involved in getting a Product Backlog item all the way to done. If a team's definition of done includes creating automated tests to validate the story, and that'd be a good idea, the effort to create those tests should be included in the Story Point Estimate. Story Points can be hard concept to grasp, but the efforts to fully understand that points represent effort as impacted by the amount of work, complexity of the work and any risk or uncertainty in work will be worth it.
Transcript Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assigned are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story is that assigned to one. It should also be two-thirds of a story that is estimated as three story points. Instead of assigning one, two, and three, that team could instead have assigned 100, 200, 300, or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers. Because storypoints represent the effort to develop a Story, a team's estimate must include everything that can affect the Effort. That could include the amount of work to do, the complexity of the work, any risk or uncertainty in doing the works. When estimating with story points, be sure to consider each of these factors. Let's see how each impacts the effort estimate given by storypoints. First, amount work. Certainly, if there's more to of something, estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page, has 100 fields, also to be simply filled with a bit of text. Despite having more fields the second pages no more complex. There are no interactions among the fields and each is nothing more than a bed of texts. there's no additional risk on the 2nd page. the only difference between these two pages is that there is more to do on the second page. This means the 2nd page should be given more story points. It probably doesn't get 100 times more points, even though there are 100x as many fields. There are, after all, economies of scale, and maybe making the Second Page is only 2 or 3 or 10 times as much effort as the First Page. Let's look at risk and uncertainty. The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item. If a team is asked to estimate a Product Backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate. if implementing a feature involves changing some old brittle code that has no automated tests in place, That risk should reflected into the Estimate. Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a webpage with 100 trivial text fields with no interactions between them. Now think about another webpage also with a hundred fields. But some are date fields, with calendar widgets that pop up. Some are formatted text field like phone numbers or social security numbers. Other fields do check some validations, as with credit card numbers, This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the users enters an American Express card a four- digit CVT field shown Even though there are still 100 fields on this screen, these fields are harder to implement. They're more complex. they'll take more time. There's more chance the developer makes a mistake and must back up and correct it. This additional complexity should be reflected in the estimate provided. It may seem impossible to combine multiple factors into one number and provide that as an estimate. It's possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item. That effort is a function of the volume of work, how much there is to do. But it is also a funtion of risk and uncertainty of a product backlog item. Depending on how an uncertainty is resolved or whether a risk hits, a Product Backlog item may take more effort to complete. And so, team members consider the risk of a problem occurring and the impact if the risks does occur. That means that a risk that is likely to occur, and will take a lot of effort to address if it does, will be estimated as more story points than an item that's neither likely nor time consuming to adress. But story points are also a function of the complexity of their work to be done. Work that is complex will require more thinking, may require trial and error experimentation, perhaps more back and forth with a customer, maybe take longer to validate, and may need more time to correct mistakes. This means complex work is given a larger estimate. Each of these factors, volume of work, risk, uncertainty, and complexity, is combined based on the impact each has on their likely effort to complete a product backlog item. Finally, when estimating story points, the team needs to include all work to fully implement an idea. A story point estimate must include everything involved in getting a Product Backlog item all the way to done. If a team's definition of done includes creating automated tests to validate the story, and that'd be a good idea, the effort to create those tests should be included in the Story Point Estimate. Story Points can be hard concept to grasp, but the efforts to fully understand that points represent effort as impacted by the amount of work, complexity of the work and any risk or uncertainty in work will be worth it.
If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?
There are multiple good reasons to estimate product backlog items in story points, but there is one compelling reason that on its own is enough to justify the use of points.
It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.
King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.
You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.
Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”
I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.
And so we argue. “30.” “60.” “30.” “60.”
We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.
So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”
Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”
And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”
The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.
But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.
Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.
Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.
What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).
And so, just as runners can agree on the relative effort required to run the same trail, Agile teams can use story points to align their estimates even if they might complete that work at different rates.
