Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
    
Possible duplicate: programmers.stackexchange.com/a/230493/31666 –  BrandonV Mar 3 at 20:13

3 Answers 3

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.

share|improve this answer
    
Thank you for your answer. However my question was about task planning and not about PBI estimation. –  Eugene Mar 3 at 9:45
    
@Eugene: Differences in story breakdown typically stem from differences in understanding the story. Such differences would hopefully come to light during the story estimation. –  Bart van Ingen Schenau Mar 3 at 10:57
    
They stem from various things, like past experience for example (even if everyone understands the story perfectly). The question is what should be done when there is disagreement. –  Eugene Mar 3 at 18:20
    
If you have disagreements because some people say they could do it faster than others, the save way is to plan conservatively. If the disagreement is to strong, however, you problably have a very unequal distribution of knowledge in the team. Then maybe you should consider pair programming of the "expert" and the "slow one". –  Sven Mar 9 at 12:29

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.

share|improve this answer
    
So you are saying that in order to save time and decrease the amount of potential disagreements teams should be divided to sub-teams where each sub-team is responsible to plan a story? But is it smart to create sub-teams with separate commitments (even if not officially recognized)? –  Eugene Mar 3 at 10:18
    
Sorry for being unclear, I didn't mean team should be divided in any way. Please let me know what gave that impression and I'll try to clarify that. –  simoraman Mar 3 at 11:05
    
You agreed with my statement "Let the person who will most likely work on the story decide.". This entails that there is basically an "owner" for each story who has the last say about task break-down and estimations. –  Eugene Mar 3 at 18:16
    
What I really meant was that don't waste time of the team on details that can be made by some smaller subset on some later time. I would think splitting stories into tasks does not require whole team, but your case might be different. If you do task splitting with the whole team, then you probably want to achieve consensus. –  simoraman Mar 3 at 21:30

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?"

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.