A Practical Guide for Agile Teams to Understand Estimation
Recently, I had a discussion with one of the Senior Scrum Masters. He asked a very interesting question about pointing defects. I’ve noticed that estimation and sizing are always hot topics during trainings. There are usually a lot of questions around this subject. People genuinely want to understand estimation—they want to crack the code, to find a magic wand that can solve all their estimation and sizing challenges. But often, they end up disappointed. There is no formula or prescription that can provide exact estimations. Whether in trainings or outside of them, estimation remains a consistently popular topic. I always try to answer these questions to the best of my knowledge and understanding.
The Struggle or Dilemma Teams Have
In my organization, teams have recently started transitioning to an Agile way of working. Before adopting Agile and Scrum, teams used to assign story points to all backlog items. This was to address management’s concerns about capacity utilization. By pointing everything, they could track where their capacity was going, who was working on what, and how many points each team member was delivering. This reflected more of a command-and-control mindset, supported by tools to monitor these metrics.
Now, with the new ways of working, where teams are encouraged to inspect, adapt, and decide how much work they can take on and deliver, many are feeling uncomfortable. There is still a mindset of expecting everything to be prescribed—where someone else makes the decisions and dictates how the team should work. As a result, teams feel uneasy when asked not to point defects and instead plan based on the outcomes of the last few sprints.
Photo by Mark Owen Wilkinson Hughes on Unspash
Understanding Story points
We need to understand the value that story points or estimations bring to the team’s work. Story points are not reward points. They are meant to help track progress and plan future sprints. The real reward is in successfully delivering a piece of the product, not in accumulating points. Velocity or story points provide insight into how much work the team has delivered in the past. This helps in guiding how much they should plan for upcoming sprints.
Should Point defects?
If a defect is found in a backlog item that the team worked on during the current sprint, there is no need to estimate or assign story points to that defect. It is considered part of the original work item, which was already estimated.
Assigning points to defects can create a misleading view of the team’s progress. A user story is intended to deliver value by providing a solution to a defined problem. When a defect is raised later, it typically means the acceptance criteria were not met. Defects indicate rework, investigation, and debugging are needed to meet those criteria. Therefore, story points should not be rewarded for defects.
Additionally, including defects in velocity calculations can obscure how much feature development work a team can realistically take on. The team’s velocity becomes a mix of feature development and defect fixes, making it harder to plan accurately. To avoid this confusion, it is recommended to estimate only feature development work—not defects. This approach ensures that, at any point in the future, teams have a clear understanding of how much feature work they can plan. It also helps provide leadership with a more accurate forecast of when new features will be delivered.
A Workaround
If you’re still not convinced and prefer to assign points to defects for reporting purposes, make sure to separate feature development work from defects when generating reports. In Jira, pull reports based only on completed stories that were committed as part of feature development work—excluding defects, and calculating average velocity for past sprints based on that. You can apply this approach across an entire release to determine how much velocity can be attributed to feature development. This data can then help you plan more accurately for future sprints.
Use Yesterday’s Weather for Planning
Yesterday’s weather is nothing but using data from previous sprints to help plan for defects in future sprints. Set aside some capacity as a buffer specifically for defect resolution. For example, if you observe that in the last few sprints your team delivered 50 story points on average using 80% of its capacity and handled 5-7 defects each sprint, you can use this data as a reference for planning upcoming sprints.
Conclusion
Many teams transitioning to Agile from traditional models struggle with letting go of the habit of pointing everything, including defects, which was previously used to track capacity and individual contributions. However, Agile encourages teams to inspect, adapt, and plan based on past performance rather than rigid metrics. Story points are meant for planning and tracking progress—not as rewards—and assigning them to defects can distort velocity and misrepresent team performance. To maintain clarity, it’s recommended to estimate only feature development work and exclude defects from velocity calculations. If defects must be tracked, they should be reported separately, and historical data should be used to plan buffer capacity for defect resolution in future sprints.