Sprint Planning Technique – Group Sorting

Do your sprint planning meetings contain a lot of disagreements and arguments? Are you spending more time trying to decide how many points a PBI is worth than it would take to develop it? Dont worry, youre not alone.

To combat this, my current team tried a technique which worked really well. Not only did the meeting take less time than normal, but more of the team were engaged and every team member was happy afterwards.

Im sure this has an official name, but Im going to call it group comparison until I find out what that is. Thankfully its really simple.

Step 0 Prepare

Hopefully youre performing some sort of backlog grooming so this is relatively quick. If youre not, this planning technique might help, but I strongly encourage you to schedule a regular grooming session. We do 1 hour every 2 week sprint and it seems to be enough. YMMV.

Print out (or create on Post-It notes) the PBIs that you think the team will be able to commit to. Id suggest a little more than your velocity after taking into account capacity.

From your planning poke decks, place the cards on the table that match the size of PBI your team can normally deliver in a sprint in a line. For us, this was 1, 2, 3, 5, 8.

Step 1 Introduce the PBIs

This is simply refreshing the minds of all the team members so they know what all the PBIs are.

Step 2 Split the team into groups.

We split into two groups, but I guess you could do more. Basically, each group is invited to come up to the table one group at a time and sort the PBIs under the poker card they think that PBI is.

Step 3 Invite the other teams

Once the first team has finished, invite the next team up. Second and subsequent teams should check the previous grouping. If they disagree with a position of the card, move it to where they think it should be. The team should mark each card with a dot to show that its changed.

Repeat this step for each group and excuse the hideous use of paint something like this:

Fig 1 – Table after grouping PBIs into story point buckets
Fig 1 – Table after grouping PBIs into story point buckets

Step 4 Discuss any significant changes

Once all the teams have finished, invite everyone back to discuss any cards that have moved twice, i.e. have two dots. It doesnt matter if theyve moved from 3 to 5 and back to 3, just discuss them so the group can have a consensus.

Step 5 Write the story points on each card

Once thats finished, there should be some sort of agreement to the size of the PBIs, so write the story points on the cards. This step is really important as were about to move them all around!

Step 6 Order by dependencies

Ask the whole team (or a subset if youre a really large team) to order these by dependencies . We used a column for each chain of dependencies and staggered them if there was some overlap, i.e. shared parents.

PBIs ordered by dependencies
PBIs ordered by dependencies

As you can see in the above image:

  • PBIs 1, 4, 6 and 7 were marked, and the team discussed 1 and 7 further;
  • PBIs 1, 6, 4 and 5 have no dependencies so can be started at any time;
  • PBI 7 has a dependency on PBI 4;
  • PBI 3 has a dependency on PBI 2;
  • PBI 2 has a dependency on both PBI 1 and PBI 6.

Step 7 Mark Dependencies

By now, the PBIs should be sorted not only by size, but it should also be clear which are dependent on another PBI and which are standalone. Simply write this information on each card ready to transfer to your tool of choice.

Final Step Task Breakdown

Perform youre task breakdown as normal and youre done.

Its important to note, that the team can change their mind about something half way through. Just because a PBI started step 5 as 8 story points and dependant on another one, doesnt mean it needs to end up in that state.

Conclusion

Once youve completed this, you should have a sized and sorted set of PBIs ready to be committed to and placed in the sprint backlog. If its anything like us, youll see the following benefits:

  • You score PBIs much quicker
  • The PBIs are scored relative to each other
  • Its easy to work out dependencies
  • MUCH less arguing
  • MUCH more team engagement

The only downside I can see, is that its possible for the business priorities to get lost in the re-shuffle. As this is limited to just the sprint and youre going to deliver them all, its not a problem.