Estimating Scrum Stories Optimally
Part of refinement and the initial sprint planning is the estimation of stories. During the second part of the kickoff (the HOW) and periodic refinement, developers take the responsibility for estimating each of the stories. Initial clarity regarding the business case and the backlog is obtained during the WHAT part of the kickoff as well as discussions during refinements. In the HOW section of the meeting, the purpose is to obtain final technical clarity before commiting to a goal.
The technical clarity includes:
- The design / architecture for the next increment (architecture is emergent)
- The technology to be used
- The impact of the definition of done on the estimation of the story
- Insight into what each of the stories entail in detail
- Breaking down each of the stories into manageable tasks or more fine grained stories for the developers to work on
- How the acceptance criteria of each of the stories will be tested
- What the implication would be for the continuous integration and deployment process if any
Before an estimate is assigned to a story, it is evaluated to make sure that it is ready to be worked on. The INVEST criteria can be helpful when evaluating the readiness of the story.
Velocity
Tracking the velocity of the team is very useful. It server as an input for team discussions as well as roadmap planning. It is a healthy practise to keep teams as consistent as possible (the same people on the teams). This helps to actually get a velocity that is useful in the long term.
As self-organisation, autonomy and mastery increase, velocity will converge to a relative number of points that can be used for further sprint estimations. This is the ideal goal. Velocity should become stable enough to become a viable metric. This might take a few sprints for each team. I have found that velocity is definitely dependent on the domain. It becomes tricky when teams start to switch domains.
Estimation using Average Velocity
Another input that can be used during estimation is the average daily velocity. Initially when teams start migrating from the SDLC approach to Scrum, disassociating from time based practices help teams get used to the intuitive nauture of dealing with uncertainty and complexity.
After the Scrum principles become clear and the teams start to understand the framework, it becomes very important to get a baseline from which accurate relative estimation can be done. Determining an average velocity per team per day has proved in the past to be useful. This would typically differ per team. For one team a [5] would be one effective team day where for another, it would be a [2]. The important focus is to start developing a consistent baseline for relative estimation.
Planning poker
A valuable tool to aid in the estimation process is Planning Poker. The Fibonacci series provides a good rule of thumb for the estimation of each of the stories. Stories should be kept as small as possible. For example any story which has and estimate of more than a [5] needs to be broken down into smaller stories.
Calibration using Bucketing
By using Bucketing, the teams start getting a ‘feel’ for what a certain estimation entails. Within a specific domain, two stories worth a [5] would ‘feel’ the same. Comparing and grouping stories increases the accuracy of the long term relative estimation of the teams. More on bucketing in another post.
The outcome
The final outcome of the process is well estimated, clear stories. These stories are negotiated into the sprint backlog and the outcome of the kickoff meeting is a clear backlog that becomes the input for the next sprint.
