Traditionally the estimates are given in days, months or person-hours with a probable end date to the project and these estimates don’t include time in meetings, email, and other non-project related activities all of this considered to be as a “PROJECT BUFFER-TIME.”
Traditionally how it happens
Estimates for our project
- One month for design and architecture
- Four months for development
- One month for testing
- 15 days of buffer time
Scenario 1 – your estimation of design is off by 2 weeks, what do you do?
You have already given the date of final deliverable. Usually, dates have an emotional attachment to them, and relative estimation removes the emotional attachment of the end date.
Scenario 2 – During the start of the project you don’t know much of the requirements to start, possibility of wrong estimations are higher.
The cone of uncertainty defines – during the start of the project the probability of estimates going wrong are very high, due to high degree of uncertainty.
“Story point represents the amount of effort required to implement a user story in a product backlog”
So while defining a story point to a particular user story in the product backlog one would consider the following factors
- Complexity ( which governs the effort)
- Uncertainty of the requirement ( which involves dependencies and doubts
So, if story points should estimate of how long it will take to develop a user story all the factors such as the risk and complexity should be factored into effort involved in implementing it. Story points represent time. This has to be so because time is what our bosses, clients and customers care about. They only care about complexity to the extent it influences the amount of time something will take.
What agile manifesto advocates is “Estimates may not be accurate, but they need to be consistent, the sprint velocity would correct the inaccuracy of the estimates” The idea to compare your last given estimates with the next estimates time and again in order to reach consistency in your estimates.
Assumptions to be made
- One of the most important considerations that need to be made while defining the story point is assuming the ideal day, where everything works as per the plan, no sick day, no one interrupts etc.
- No individual task should be more than 16 hours ( you can decide a number to define based on your project
- Assuming that your team size is constant and team understands their roles
Identification of the base/reference story
Breaking of the user stories until you reach to a small story which cannot be further broken. Making this is a base story or the reference story based on which you would relatively estimate the product backlog. This is important to create the initial product backlog.
Tuning the base/reference story
After the team has created the initial product backlog, pick one of those stories that are a good representation of an “average” story from that list few user stories and do a relative mapping to the story against the average story and assigning a story point to this reference story and realign the product backlog with the new number. The product backlog grooming is a continuous process which happens throughout the entire project.
Techniques of estimating
There are various techniques for assigning user story points to a user story. Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.)
Agile emphasises that the story point estimation should happen at the story level not at the task level
The estimation should not happen at task level but at the user story level as some of the tasks might not be required as we come closer to the final delivery of the user story or even the user story may get dropped during the sprint planning meeting. One of the key things to remember during the estimation is working with the product owner and identifying the user story which is the most granular part of the product backlog which means it is simply small or needs to be split. As a part of the sprint meeting the team needs to define two key points would the team able to take this user story in the current sprint or this need to be broken into smaller deliverable user stories.
Learn from past estimates
Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools tracks story points, which makes reflecting on and re-calibrating estimates a lot easier. For example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. Use that insight in future estimation discussions.
Like everything else in agile, estimation is a practice. You’ll get better and better with time.