Self-organization during Sprint Planning

Question

During Sprint Planning there are a lot of decisions to be made:

1. How many PBIs should the team commit to?
2. Which tasks should constitute each PBI?
3. How much time should each task take?

With no team leader it is not always easy to make all these decisions, since there will be some decision points (sometimes more than a few) in which the team members will disagree.

I thought about a few options to deal with such disagreements when a consensus cannot be reached in a short period of time (we don't want endless arguments).

1. Let ScrumMaster decide
2. Let the person who will most likely work on the story decide.
3. Majority vote
4. Let the person who actually writes the tasks in Excel decide (in such case have a different person write the tasks for each story).

I have two questions:

1. How to measure consensus? Should the Scrum Master ask each person whether they agree with every decision proposed?

2. When no consensus can be reached shortly, which option from the list that I proposed do you think we should choose, if any?

Thank you!

Answer 1

First, the only ones that can decide how much work they take on, are the team members. They have to commit to the work. If somebody else (Scrum Master/Team Leader/...) would decide, it wouldn't work, because then the team could blame somebody else for assigning to much work, if they didn't finish.

Apply the concepts of time boxing and an "anonymous" estimation technique like Planning Poker to achieve consensus. Example: Give the team 2 minutes to briefly discuss the story. Make them play a round of poker (there's the possibility to give your own judgement without knowing what the others will do). If they agree, fine. If they differ slightly, it's usually easy to settle for one. In case of uncertainty, take the higher estimate. If they strongly disagree. Give them another 2 minutes to discuss why. Then play another round of planning poker. In my experience, this approach leads to a consensus pretty fast. You could call this an iterative majority vote...

After the estimation, every team member should have a pretty good idea what needs to be done in order to complete the story. Otherwise they did not understand the problem in the first place and were unable to give a good estimation. In consequence, every team member should be able to break down the stories to tasks. However, this is unrelated to estimating and taking on stories. In my opinion, concrete tasks should be defined only after the the sprint's stories were selected. Everything else ruins the relative-estimation idea. Usually, we just each select a story and break it down, till all tasks are defined. Then the breakdown is reviewed by the members that didn't do it. Takes less than 15 minutes.

Answer 2

In two years of doing scrum, we've never failed to reach consensus. Measuring consensus is simple: just ask if there are any open concerns about the plan. Watch for people who don't speak up, but are shaking their head. Don't end the meeting until everyone is on board.

The great thing about scrum is your mistakes don't last very long. The worst I've ever had to do to gain consensus is say something like, "You may be right, but the rest of the team disagrees. Are you willing to try it for two weeks and reevaluate in our next retrospective?"

Answer 3

How to measure consensus? Should the Scrum Master ask each person whether they agree with every decision proposed?

I prefer thumb voting or fist of five for checking consensus. Having everybody express their opinion simultaneously makes it less likely for the opinions of strong personas in the team to affect others.

Let ScrumMaster decide

Role of Scrum Master is to serve and coach the team. I don't think he should make decisions on how team does their work.

Let the person who will most likely work on the story decide.

People who work on a story are the ones responsible for it and should have the power to make decisions on it. However decisions about details should be deferred until work on a story starts. Sprint planning should be quite high-level.

Majority vote

This sounds best to me. Measure consensus, discuss, vote again until consensus has been achieved. Note that consensus does not mean everybody agrees, it means nobody wants to block progress. If somebody wants to block progress, you need to discuss it, no matter how much in a hurry you are.

Let the person who actually writes the tasks in Excel decide (in such case have a different person write the tasks for each story).

Does this mean splitting stories in to tasks? If so, it is similar to number two, those who work on the story also split it in to tasks and make decisions that need to be made.