It is incredible how many questions I get about how to point out stories. I am not sure this topic deserves its own blog, but every team I have ever worked with has asked, “Should I point this story? It’s so small; it isn’t even a one-pointer!” Let me spend a few moments on thoughts concerning zero-point stories and some other best practices concerning pointing (estimation).
Definitions:
Story Points: In Agile methodologies, particularly Scrum, a “story point” is a unit used to estimate the work required to implement a story, feature, or functionality. Story points are abstract measurements that allow development teams to understand the relative complexity of tasks compared to each other. [See WTF Is a Point for a detailed description of a story point.]
Going from Suck to Awesome
Suck – Starting a Sprint with un-estimated stories.
Still sucks – Starting a Sprint with some stories pointed and other stories not pointed.
Sucks a little less – Starting a Sprint with all stories pointed out, but not all tasks were included in the Sprint, even though they were essential but minimal.
Awesome – All stories have estimates, even tiny stories.
Estimating Zero-Point Stories
Why Would Anyone Estimate a Story at Zero Points?
Great question. Some teams don’t. Sometimes, teams assign a half point or a single point to small stories. Let’s talk about the downside first, and then I will cover the possible upsides of pointing to a zero-point story.
The downside of not including important but small stories is that they may be skipped, forgotten, or unprioritized. I am not a fan of “shadow” work queues. Everyone has day-to-day tasks that aren’t included in the Sprint planning, but when a story or task is essential to the team, the work should be planned, detailed, and prioritized with the team.
The downside of pointing out even the most minor story or task at one point is that it warps the actual story estimate. All one-point stories should involve the same effort, complexity, and uncertainty. Some one-point stories may require more effort, and some may be more complex, but overall, they should meet the criteria of a one-point story. If the team is just putting a point on a story because there is no other option, then it degrades the value of estimation.
There are several upsides to assigning zero points to tiny stories, including:
Practice: The mere fact that the team points a story to zero points helps the team practice estimating. Choosing zero points indicates that the team had to explicitly decide that the amount of effort, complexity, or uncertainty was significant to warrant any points.
Accountability: A story has many more attributes than its points. For example, each story usually has at least one person assigned to it. Adding zero-point stories to the Sprint will help determine how to distribute work.
Documentation: Tracking zero-point stories can be helpful when looking back at previous work. Some work is very repetitive, and having a record of the required tasks is helpful.
Clarity in Backlog Management: Zero-point stories can clarify the backlog by identifying necessary tasks that are too small to estimate. Pointing information on a story can help keep the backlog clean and focus on value-adding items.
Improved Estimation Accuracy: The team acknowledges their presence without affecting the velocity calculations by marking specific tasks as zero-point stories. Not inflating total points for a Sprint helps estimate sprints more accurately.
Acknowledgment of Necessary Work: Zero-point stories recognize the effort involved in essential tasks but not substantial enough to be estimated as a full story point. Examples may include minor bug fixes, small refactoring, or documentation updates.
Better Sprint Planning: Including zero-point stories in Sprint planning can provide a more realistic view of the team’s workload, ensuring unacknowledged tasks don’t overstretch capacity.
Transparency and Visibility: It offers visibility into all of the work being done by the team, including tasks that are often overlooked, which promotes transparency in the team’s process.
Why Shouldn’t I Leave the Estimate Value Blank?
Again, good question! Why not just leave the value blank? One guideline I always try to reinforce is the lack of clarity can lead to mistakes and unnecessary risk. Un-estimated stories make it hard to determine if they were intentionally or unintentionally left blank.
Advanced teams may have automation that rejects or flags un-pointed stories. It may slow down planning because it could confuse what stories have been discussed and which still need to be reviewed.
Injections happen [See “How to Best Handle Injected Work into a Sprint”], especially with new teams, and these tickets are more likely to enter a Sprint without estimates. It is more evident if all stories are pointed, and suddenly, a new story appears without points. This is more common with tools that support stories created via alternate tools, such as an email gateway.
Using Fractions and Other Methods to Indicate Less than One Point
Depending on your Agile planning tools, it may be possible to use fractional values. I am not a fan of fractional values, even though there isn’t anything wrong with using fractions. Most tools display a half point as .5. Unfortunately, it’s easy to miss the decimal point, especially for people like me whose vision isn’t that great anymore. The .5 points may be read as 5 points. Once again, this violates the concept of clarity.
In addition, it is harder to distinguish between .5 and 1 point than it is to distinguish between 3 and 5 points. One of the compelling reasons to use points is to avoid arguments between close values such as 1 hour and 2 hours. Half points are just too small to distinguish from one-point stories.
Overdoing It?
Like everything else, a team can overdo a concept or idea. A Sprint with 100 zero-point stories would be ridiculous. Typically, a zero-point story would enter the backlog un-estimated, and the team would point it at zero points when they plan. If the team must review every little item and mark it at zero points, it will degrade the value of planning. Not every task needs to be included in planning.
There are other adverse side effects of too many zero-point stories. For example, finding one story is more burdensome if a Sprint has dozens of stories. Essential stories may be lost in the mix.
Conclusion
In conclusion, assigning zero points to specific stories in Agile methodologies, particularly Scrum, serves multiple purposes that enhance the overall efficiency and clarity of the development process. These zero-point stories help in practicing estimation, ensuring accountability, providing documentation, clarifying backlog management, improving estimation accuracy, acknowledging necessary but small-scale work, aiding in better Sprint planning, and promoting transparency and visibility into the team’s work process.
Teams should avoid leaving estimates blank, as this can lead to confusion and risks due to a lack of clarity. Although some teams might consider using fractional values for small tasks, this approach can sometimes compromise clarity.
Moreover, while zero-point stories have benefits, it’s essential to avoid overdoing it. An excessive number of zero-point stories can overwhelm the team and detract from the value of planning, making it challenging to focus on essential tasks.
A balanced approach, where zero-point stories are judiciously used, can ensure that teams reap the benefits of this practice without falling into the pitfalls of overuse. This balance is vital to maintaining a productive and effective Agile environment.
Comentários