Backlog refinement and spikes are both about reducing uncertainty and they often lead to the same outcome: a clear understanding of future work. But there are important differences. In this post, Dan Greenberg explains them and provides some tips on when to use them.
When a team is unsure how to move forward with their work a useful practice is to schedule a timebox in which a couple of team members (or the whole team if the uncertainty is preventing them from working on the customer’s highest priority) address the unknowns. They can gain the necessary knowledge through research, by building a prototype, collaborative brainstorming, or any other means.
In the spirit of transparency, this work is called a spike. A time limit is put on it, and, when the time limit is reached or the uncertainty is resolved (whichever comes first), those involved share their findings. Agile lore suggests the term comes from the pitons used in mountain climbing; pitons are small spikes that, once driven into a rock face, provide a secure anchor for carabiners. The spike does not move the climber closer to the top, but it does enable her to make further progress.
Backlog refinement brings a team together to review and revise upcoming work items. The objective is to get work “ready” for the team, so that they can pick it up and make progress against it. There are different approaches. Scrum recommends spending no more than 10% of a team’s time on refinement but leaves the specific approach up to the team. Kanban teams will apply explicit policies: if items are “ready” they can be brought into the system when capacity is available; if not, further refinement is necessary. Some Kanban teams visualize this “upstream” work to the left of their implementation board.
My experience suggests that it’s best to create a regular cadence of sessions, a couple each week, to bring the team and their stakeholders together so that they can examine outstanding work and gain broader understanding of upcoming items.
Backlog refinement and spikes are both about reducing uncertainty. They often lead to the same outcome: clear understanding of future work. The difference is in the source of the uncertainty. If the uncertainty is around implementation details—the “how”—then it is best to bring development team members together for a spike. If the uncertainty stems from the value the team is expected to deliver—the “what” and the “why”—then it is best to get together with stakeholders, clarify details, and create shared understanding through the work of refinement.
I like the INVEST criteria. Each ready backlog item should be:
Other teams will create a “Definition of Ready” with similar details. Here’s an example:
“Ready” is very contextual. Team members should ask useful questions like the following:
Please share your own thoughts and experiences on refinement and spikes!
Agile eXamined: The Sprint Goal
Daily standups, acceptance criteria, user stories, retrospectives…am I right Agilists? In the day-to-day, it’s easy...
Agile eXamined: Alternatives to User Stories
A To-Do List is the backbone of each program/effort/project. It doesn’t matter if you use...
Agile eXamined: The Daily Standup
In this issue of Agile eXamined, Dan Greenberg looks at the intent and objectives of...