As discussed in a previous post, Backlog Refinement is a workshop held to take large backlog items and slice them down into smaller pieces. More specifically, we discussed the three major goals of Backlog Refinement:

1. Estimate backlog items that have no estimate
2. Correct estimates that appear to be considerably off target
3. Discuss backlog items and divide them into smaller component pieces (slicing).

In this blog post, I want to discuss how we make sure that the Scrum team refines enough backlog items for the next Sprint. If the team refines too little, they will experience problems with their Sprint Planning meeting and the Sprint (both will be difficult with unwanted surprises appearing during the meeting). If the team refines too much, they will risk creating the same problem that Backlog Refinement is supposed to solve – making too many decisions before the team is ready to build.

We know how many backlog items to refine before we can stop by adding up the story points of the backlog items that are “ready” and comparing the answer to our team’s current velocity. This all goes back to the lean principle I mentioned previously, “Defer decisions until the last reasonable moment.” As mentioned in the blog post on how small we need to slice backlog items, our target size for “ready” backlog items are items that can be built by 2-3 people on the team in less than one week. Larger than that increases the risk of unwanted surprises during the Sprint. Smaller than that increases the risk of making detailed decisions that don’t need to be made before Sprint Planning.

Minimally, we want to refine enough backlog items during Sprint “n” that there are sufficient small backlog items or Sprint “n+1.” At first, before the team has established a predictable velocity (meaning that they are completing a predictable number of story points each Sprint plus or minus 10-15%), you have to guess at how many is enough. Chances are, if your team is so new that they don’t have an established velocity (which takes about 3 iterations), they probably will need extra time for refinement anyway, so you should hold 60-90 minute refinement sessions two times a week for the duration of the Sprint. Once the team has an establish velocity, you should hold refinement sessions until there is enough properly sized work on the top of the product backlog that the sum of the properly sized items is equal to or slightly exceeds the team’s velocity. This ensures that there is always enough work on the product backlog to support the team in backlog refinement.

In many teams, still is always a chance that a backlog item that appears properly sized and ready at Sprint Planning will prove to be unusable or not ready or may even be removed from the Product Backlog by the Product Owner prior to Sprint Planning. To deal with this possibility, many teams will refine a little more than their velocity, just in case some of the “ready” backlog items end up being removed. In this case, instead of refining enough for the team’s velocity (that is, 100% of the team’s velocity), the team might refine 110% to 125% of the team’s velocity. So, if the team’s velocity is 20 story points per Sprint, the team might choose to refine up to 25 story points, just in case some of the refined items end up being de-prioritized or removed before Sprint Planning. How much extra is refined should be based on common experience and a team decision to refine more than their velocity.

Regardless of your approach, once you have refined the number of Story Points that the team wants prepared for Sprint Planning, you can generally cancel all remaining Backlog Refinement meetings for the remainder of the Sprint.

Be sure to continue by reading part four!