Making Estimations Simpler
27 October 2017
I asked my Scrum Team to estimate user story A, and after a good game of Planning Poker, they came up with a number that was accurate and achieved. It felt like a great success — and that was when I woke up and remembered that I was in the real world.
Estimating user stories is a challenge in Scrum. What makes it so difficult? Is it the complexity of the user story, the lack of information, not understanding which factors need to be considered while estimating? The list of possibilities goes on.
It’s important to remember that an estimate is only an estimate and not an oath; you are not required to stretch your schedule just because something was originally underestimated.
Below are a few other points to consider while estimating.
Get the right input from the product owner
The product owner is responsible for gathering requirements, breaking them down into user stories, and maintaining them in the product backlog with related priorities. This individual will be the primary contact for the team to discuss any queries regarding user stories. But the product owner may not always understand the details of implementing a particular functionality. When the team begins its estimation process, questions arise about requirements and user stories — questions that help the entire team understand the work more fully.
Estimate the smart way
The accuracy of the estimates improves if the whole team is involved in the estimation process. This involvement also increases the team’s buy-in and support of the estimates.
When estimating, it’s a good idea to involve designers and testers to get different perspectives. Each team member can have a different estimate for the same user story, depending on the experience the member possesses. Set a threshold point. For example, if story points are used for estimation, you may decide that 20 points is the upper limit. When something is estimated above the team’s 20-point threshold, that’s a signal to break it down into more granular pieces and reestimate. It’s good practice to give a rough estimate for the work items that are likely to change.
Use story points for estimation
A story point is a metric used for estimation in Agile. It is not a measure of time needed to complete a feature but a measurement of feature size relative to other features. This is helpful because you may not have enough information to estimate the time needed to create a feature, but you can immediately compare the sizes of features to each other to determine a relative size. This comparison is quick to obtain by using the story point estimation technique.
When using story points for estimating, Planning Poker is a good technique. The team selects an item from backlog, discusses it, and then each member mentally thinks of an estimate, usually in some variation on the Fibonacci number format. Next, everyone holds up a card with the number that reflects his or her estimate. The numbers usually vary from member to member. The team will take some time to discuss this differences and then reach a consensus. It is also important to periodically ensure that all 2s are about the same, all of the 4s match, and so on.
When using story points, it doesn’t matter whether your estimates are correct or incorrect as long as you are consistent. Tools like JIRA track story points, which helps the team reflect on and recalibrate estimates more easily.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 2.8 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.