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?
That effort is a function of the volume of work
How much there is to do but it is also a function of the risk and uncertainty of the product backlog item
depending on how an uncertainty is resolved or weathera 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 risk 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 then an item that is neither likely nor time-consuming to address
But story points are also a function of the complexity of the work to be done work that is complex will require more thinking
May require more trial and error
Experimentation perhaps more back-and-forth with a customer may 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 the 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 and 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 would be a good idea
The effort to create those tests should be included in this story point estimate
Story points can be a hard concept to grasp
but the effort to fully understand the points represent effort as
Impacted by the amount of work the complexity of the work and any risk or uncertainty in the work will be worth it