Agile eXamined: Backlog Refinement and Spikes

What is a spike?

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.

What is backlog refinement?

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.

What is the difference between a spike and refinement? How do we know which one to use?

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.

What makes a backlog item “ready” to be worked?

I like the INVEST criteria. Each ready backlog item should be:

• Independent – free of dependencies and not reliant on any other backlog item.
• Negotiable – a placeholder for a conversation rather than a rigid set of requirements; the “what” is specified but the “how” is negotiable.
• Valuable – something whose value is clearly understood by all team members.
• Estimable – small enough and clear enough that the team can reliably estimate its level of effort.
• Small – able to be completed in half a sprint or less.
• Testable – written in such a way that it is easy to tell whether or not it is done.

Other teams will create a “Definition of Ready” with similar details. Here’s an example:

• Not too large; we expect to complete this change in a week or less.
• Acceptance criteria documented and understood; we know when we will be done with it.
• Value documented and understood; we know why end-users want this and the value they expect it will bring.
• Proposed technical approach is sound; we are confident our existing skill and knowledge will allow us to introduce this change.

“Ready” is very contextual. Team members should ask useful questions like the following:

• “If I were to start work on this item today, would I know how to proceed? What unknowns do I need to address to get to that point?”
• “Do I understand the goal of this work?”
• “Who derives value from this feature and do I understand why?”
• “Do I feel confident that my team—with the skills and talents that we have—can deliver this work in a short period of time (in a single iteration)?”
• “If we need help from outside of our team, can we get it in a timely manner?”
• “Does anything about this feel inaccurate or misleading?”

Please share your own thoughts and experiences on refinement and spikes!