How to Estimate with Story Points in Agile
It is one of the most difficult aspects of work for software developers. You should take into account a range of factors that help product owners make decisions that affect the entire team and business. to senior management easily get their underwear. But this is a mistake. Agile estimates are just: an estimate not a blood-oath.
There is no requirement for weekend work to compensate for undervalued work. That is, let’s look at some ways to make Points in Agile estimates as accurate as possible.
What Goes Into A Point in History?
Because story points represent an effort to develop a story, the team’s estimate should include anything that might affect the story. This may include:
- Amount of work to be done
- The complexity of the work
- Any risk or uncertainty in the performance of the work
Amount of Work To be Done
Of course, if there is more to be done, the estimate of effort should be greater. Consider the development of two web pages. The first page has only one field and one tag, asking for a name.
There is no interaction between fields, each field is just a little text. There is 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.
The second page should give more points in history. Even if there are 100x fields, you may not get 100x more points. After all, there are economies of scale, and maybe make the effort of the second page only 2 or 3 or 10 times the first page.
Risks and Uncertainty
The risks and uncertainties in the product accumulation project should affect the estimation of the history point given to the project.
If a team is required to estimate a backlog output and interested parties request that it be unclear what will be needed, this uncertainty should be reflected in the estimates.
If implementing a feature involves changing a specific fragment of old fragile code that does not have automated testing, the risk should be reflected in the estimate.
Complexity
Complexity should also be taken into account when providing estimates of points in the story.
Recall the above example of developing a web page that contains 100 simple text fields and has no interaction between them.
But some are the date fields of the calendar widget that appears. Some are formatted text fields, such as phone numbers or social security numbers.
If the user enters a Visa card, a three-digit CVV field is displayed. However, if the user enters an American Express card, the four-digit CVV field is displayed.
Even if there are 100 fields on this screen, these fields are more difficult to implement, more complex and take longer. Developers have more chances to make mistakes and have to back up and fix it.
This additional complexity should be reflected in the estimates provided.
Consider all factors: Workload, Risk, and Uncertainty, as well as the Complexity.
It may seem impossible to combine all three factors into a single number and provide it as an estimate.
However, because the effort is a unity factor. The estimator considers how much effort is needed to complete the workload described in the product portfolio.
The estimator then considers how much effort is needed to address the risks and uncertainties inherent in the product accumulation item.
Usually, this is done taking into account the risk that the problem occurs and the impact that the risk occurs. Risks that are likely to occur than a mild and unlikely risk.
The estimator also considers the complexity of the work to be performed.
Complex work requires more reflection, may require more trial and error experiments, perhaps more customers back and forth may take longer to verify and may take longer to correct errors.
Consider Everything in the Final Definition
The story point estimate should include all the elements involved in obtaining product delays.
If the definition of team completion includes the creation of automated tests to validate the story (which would be a good idea), the work on creating those tests should be included in the story point estimate.
History points can be a difficult concept to understand. However, it is worth trying to fully understand the amount of work represented by the points, the complexity of the work and the risks or uncertainties at work.
We hope that the blog was helpful and you will now be able to estimate story points more accurately for your Agile projects. Do let us know your queries.
