What Are Story Points And Why Do We Use Them In Agile?

Story points our 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 assign are unimportant What matters are the relative values a story that is assigned at two? Should be twice as much as a story that is assigned a 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 one hundred two hundred and three hundred or 1 million two million and three million it Is the ratios that matter not the actual numbers?

Because story points 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 work? When estimating with story points be sure to consider each of these factors Let's see how each impacts the effort estimate given by story points first the amount of work Certainly, if there's more to do of something the 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 page is no more complex There are no interactions among the fields and each is nothing more than a bit of text.

There's no additional risk on the second page The only difference between these two pages is that there is more to do on the second page This means the second page should be given more story points It probably doesn't get 100 times more points, even though there are 100 times as many fields there are after all economies of scale and maybe making the second page is only 2 or 3 or 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 be reflected in the estimate Complexity should also be considered when providing a story point estimate think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them Now think about another web page also with a hundred fields But some are date fields with calendar widgets that pop up Some are formatted text fields like phone numbers or social security numbers Other fields do checksum 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 user enters in American Express card, a four-digit CVV field is shown Even though there are still 100 fields on this screen These fields are harder to implement their more complex. They'll take more time. There's more chance The developer makes a mistake and must backup 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?