A long time ago, on a Scrum Team far, far away…
Scrum Team A-Tano, responsible for creating navicomputer software at Corellian Engineering Corporation—and the same team that recently learned how to tackle sprint work that ends early—encountered a new challenge: falling behind in their current Sprint.
Inundated by work, the development team unanimously agreed that they should cancel their Backlog Refinement session so that they could catch up on their work.
Now, with the team, the Scrum Master, Inez, asks in protest, “Didn’t we skip the Backlog Refining session last Sprint?”
“We had to,” one of the developers says. “One of the stories took longer than we expected, and we didn’t want to let the product owner down.”
Grady, the team’s architect, says, “But that ended up putting us even farther behind, because we didn’t understand the stories as well as we should have.” He added, “It sounds like skipping refinement is the LAST thing we should do.”
The room fell silent for a moment, and then everyone started to talk at once. When they calmed down, they started to talk about five reasons why they shouldn’t skip backlog refinement—and why it’s crucial for agile planning:
Skipping refinement borrows from the future
Skipping refinement is really just about avoiding the inevitable; it defers an activity that, at some point, must be paid for. And the more items that are deferred, the more difficult it becomes to work through all of them. So, when you push refinement into the future, you’re almost ensuring that more time must be taken to do the same activity.
Also, the more time that elapses between when a story is first conceived and when it is refined, the greater the gap in understanding of the story’s purpose. That gap broadens the scope of refinement, from “how can we make this story clearer or smaller,” to, “how does this relate to what we’re building in the first place?”
Well-refined stories help streamline Sprint Planning
When teams look at the stories together, they are less likely to be surprised by the story details and misunderstand the acceptance criteria. When the team understands the stories, they have time to identify necessary tasks and make a good plan for the sprint.
In Scrum Team A-Tano’s case, in the previous Sprint Planning, the team spent so much time arguing over the meaning of stories that they didn’t really understand what needed to be done, and they didn’t identify enough tasks to accurately plan their work throughout the Sprint. Had they taken the time to refine, they would have had a better understanding of what work was most important for the sprint.
Refinement promotes team alignment
By refining the backlog, teams can close gaps in their understanding of the stories and become closely aligned on the work. The most effective teams have a shared understanding of the work to be done to solve the business problem at hand. To create a shared understanding, conversation must take place. This is what refinement is all about!
For example, let’s say one of Scrum Team A-Tano’s stories was to calculate a cargo route around an asteroid field: one developer thought that they had to account for every large asteroid in the field, but another thought that only large rocks within blaster range were important. That led to a lot of arguments as they developed and tested the story. If the team had agreed on the parameters earlier, it would have saved them a lot of time.
Refinement exposes hidden complexity
Often, when teams refine a story, they discover that the story contains hidden complexity that will require much more effort than originally thought. These stories often need to be split into smaller stories or may require a research spike before the team can begin working on it. If the team doesn’t discover this complexity before Sprint Planning, they may feel under pressure to accept stories into the sprint that are really too large, or that can’t be done right away.
For example, a seemingly simple route calculation may not be simple to deploy to legacy hardware—therefore, the team might have to write new code that they weren’t counting on. Refinement exposes these complexities that may otherwise go unnoticed and do more harm down the road.
Refinement reveals dependencies
Often, the work to complete a story will impact—or be impacted—by other stories. During refinement, these dependencies get uncovered—then the team can choose what to do about it. They may highlight the dependencies so the team is aware of them and can collaborate in the best way to address them. They may sequence the work, so the downstream dependency is completed first, thus reducing the dependency on the other work and allowing the work on subsequent stories to go faster. Or they could split or combine the stories to remove the dependency and increase the team’s speed of delivery.
As Scrum Team A-Tano discusses the benefits of refinement, a developer exclaims, “Of course! It all makes sense now. The key reason we’re too busy is the lack of refinement from the past Sprint, so I vote to continue with today’s planned Refinement.” The rest of the team agrees, and once again, there is temporary balance in the universe.
