Structure: Expose the optionsDuring the planning meeting there was a moment when the overall group energy was very low, but there were three guys intensively discussing about the subject having different opinions what to do next. There talked about their argument so passionately that it was very easy to get lost and miss the point, and I am afraid they also weren't sure what the other side is talking about. Then I suggested:
- Only three people are discussing here, the others are bored. Let's name the options you present and whole the team will vote and choose the solution.
And one of the team member got the pencil and started to write on the board:
- let's do the task as much as are able to, let's hope we will finish it in this sprint
- let's divide it into smaller items, and choose the subset we will do for sure
- let's take it to the refinement and we will do this item in the next sprint
Five people voted on second option and two people on the third. The decision was made.
What kind of structure you can find here?
When: group or just a few people are discussing intensively
1) notice that you can see not everybody is engaged or the decision far from being made
2) ask for naming the options (it would be great to write it so that everybody can see it)
3) vote on the options (you can do it similarily to the planning poker game)
4) if there is a draw: draw the option (or have any other arbitrary method to choose the option)
Structure: Structuring Planning meetingWhen the particular type of meeting tends to be chaotic it is good idea to introduce structure to organize it.
When I thing about Scrum Planning meeting I like to seperate the steps of planning (a few selected steps):
1) The team browses the items that
a) have been refined recently
b) weren't finished in the last sprint
c) are at the top of the backlog
Browse means to remind very shortly intention of the item and not going into details.
2) Product Owner supported by the team prioritetises (expressing why) and chooses the items that are the strongest candidates to be chosen to the current sprint. In many cases it means that the weakest candidates are removed.
We do it so that we will not discuss about things that are not going to be developed in the sprint.
3) Starting from the top (the highest priority item) Product Owner presents (or reminds) acceptance criteria for the item and the team estimates it (supposing that items are refined enough to get estimated). This is also time to talk about details if it is neccessary.
Product Owner presents all the items (one by one) and then the team has time on its own to do some brush desing and make estimations.
4) Team chooses how many items they can do so that they can make a reliable commitment.
No matter what kind of structure you use it's important to keep the borders of the steps clear - especially not to talk about details to early (or maybe not to talk at all).