Skip to content

Accelerate Sprint Planning and Estimation

One of the most challenging points in sprint planning is gauging what is worth tackling for the next sprint. Product owners cheerfully come up with ordered lists of their favorite user stories, but typically falter when it comes time to make hard choices of what they want ready at the end of the upcoming sprint.

What if a story is large but very desirable? Do you trade it for 4 smaller, but lower priority stories just to get more features done? What if there are many small stories and 1 large one, but the large one is lower priority? Do you squeeze it in by dropping a small story or split it so the higher priority smaller stories can be delivered? Since stories are not immutable and can be split, opportunities for many tradeoffs exist. But how to manage them? How to visualize those tradeoffs?

Inspired by Steve Bockman’s Team Estimation Game, I added another dimension: Priority, and came up with an effort-priority quadrant for facilitating the difficult tradeoff between effort and priority during sprint planning. I tried this out several times with a complex product and diverse team, gaining quick and lasting agreement on planned work for the sprints.

Since no one can properly estimate what they don’t understand, the team reviews the stories in advance with the product owners to get an idea of what needs to be built and what it might take. Ideas for preliminary tasks or steps are appended to the story description to make it more relatable to the development team. Additional acceptance criteria are added as discovered.

To prepare for the estimation, write or print out the stories on cards or stickies so they can be positioned anywhere on a wall or whiteboard. Write discovered tasks on stickies or labels and append to their stories so the tasks can be moved together as a ‘package’ or moved to another story. You could also just write them on the story cards and rewrite them as needed.

Graphical Instructions are in this slideshow:

At closing, hold a 5 minute meeting review (mini-retrospective) with team or just by ScrumMaster and product owner and tech lead for how things went

Of course, the ScrumMaster needs to represent all stories and tasks in an issue tracker, document repository,story map and/or agile wall to reflect effort estimation and updated priority

    I hope this is clear enough for you to adopt this tool to facilitate easier sprint planning. Please let me know what you discover, improvements, advantages and drawbacks.

    Posted in Techniques.

    0 Responses

    Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

    Some HTML is OK

    or, reply to this post via trackback.