Improving your Sprint Backlog through Refinement

I see a lot of teams spending far too much time in sprint planning.  A full day of planning for a two week sprint, for example, consumes 10% of the team's available time and rarely produces enough accuracy to justify the cost.  Often, the impulse for spending so much time in planning is that the team, or management, wants a reliable forecast of what the team will accomplish by the end of the sprint.  The problem with this is that the features, the work needed to accomplish them and the challenges the team will face, aren't so precisely known.  Therefore the initial plan can't be precise either.

A better approach, when facing such uncertainty, is to create a rough initial plan, with some detailed first steps, and revisit the plan as more is known and the next steps are needed.

An Example
The team working on a Parkour mechanic is implementing some IK motion and wants to blend it with animations.  They're not sure what will look good or what type of animation or blending will be needed, or even if they'll have time to iterate on animations once the IK is in place.  Rather than try to plan all the work out on the first day of the sprint, they'll spend an hour and identify the initial tasks to try IK in place.  Near the end of the week, they'll spend another hour discussing their progress and identifying the next steps to take, including what animations they'll want to try blending in.

Note: there will likely be other stories for the animators to work on or they will be shared with another team.

Benefits
By spending a quarter of the time, the team will have more time to spend on the feature and actually identify the work more accurately: it will respond better to the emerging mechanic and iterate more effective, rather than relying on the initial plan being correct, which was based on a good amount of assumptions.

Pushback
So why don't more teams do this?

• Trust: Management often wants to see a detailed plan coupled with a firm commitment to achieve that plan.  They don't yet trust the team to "wing it" with uncertain features.
• Certainty is preferred over maximizing player value: Many organizations are task focused: a developer's success is measured by how well they meet their scheduled assignments.  Using an emergent sprint backlog requires a "value added over task estimate" approach acknowledging that work emerges to achieve a value focused goal.  This requires the ability for the team to safely say "we don't know".

An emergent sprint backlog requires improving trust and leadership.  Leaders need to move from being remote task managers to local mentors helping developers become better at:

• Responding to emergence
• Being accountable to value and quality
• Communicating with courage, rather than hiding behind a task list out of fear.

This takes time, but it is well worth it.