My team hates planning poker (and the length of planning in general), is there a more engaging and/or quicker way to plan a sprint?

Question

My team hates how long we spend in planning. We're currently spending about 3 hours for a 2 week sprint. I tell them that is actually less than a by the book sprint planning, but regardless they want to see what else is out there/ Are there either more engaging ways to plan a sprint (something other than sitting around a table playing with cards/shouting out t-shirt sizes), or a quicker way to do it?

Answer 1

This is a concern I've heard multiple times and the trouble with it is that if it takes a long time, it needs to take a long time. What I mean by that is that the goal of estimation is less about the number in the end and more about driving out understanding. Sure, your team might be squabbling over unimportant details (if every story is a fight over a 3 or 5, pick one, move on, don't sweat the small stuff). But usually the long conversations are when someone holds up a 2 and someone else has a 13 because they have very different views of what the backlog item means or how risky it is to implement. These are the conversations that need to happen with the team.

That doesn't mean you can't help. Look for patterns in these conversations. Are there personal conflicts that artificially create disagreement? Are there knowledge gaps that lead to the same arguments over and over again? Are there technical pitfalls in the application or outside organizational pressures that make people fearful of touching some features? You can point these out to the team and help them clear them away so they aren't cropping up as often. But ultimately, if the reason it takes a while is because the team needs to uncover important facets of the backlog item, there is no good way to hop over that without it catching up to you as problems in the middle of the sprint (and you'll pay much more time for them then).

Answer 2

Different teams have different approaches to estimating.

Some teams I have worked with like to do all of their estimating in sprint planning and as a result it often takes several hours.

Other teams hate long meetings and so they prefer to do more estimating as a part of backlog refinement. For example, one team I worked with does 2-3 backlog refinement sessions per sprint and usually has 90% of their estimating done before the planning meeting.

It is also worth questioning if you need estimates at all. Experienced Scrum teams can get very good at making their stories small and (relatively) predictable. When this is the case, a story count is often sufficient to estimate the capacity of a sprint.

One word of caution with this approach though. Estimating is a valuable process, even if the estimates themselves are not that important. The act of estimating often draws out some issues and helps the team to synchronise their efforts.

As with all things Scrum, the best thing to do is to experiment and see if things get better.

Answer 3

TL;DR; It sounds like the value that is supposed to be gotten from Sprint Planning is being lost. Its part of the empirical process and provides inspection and adaption: You should be inspecting the Product Backlog and adapting a Forecast, Sprint Goal, & Sprint Backlog.

There are many other 'games' that can be used for estimation &/or planning and may can be found on http://tastycupcakes.org/

The Problem

I would be surprised if they are engaged enough to create great software.

If you turn up at your Sprint Planning event and the next 2/3 Sprint worth of your Product Backlog are not in awesome shape then you are going to be in a world of hurt. You will not have time to:

• Create estimates with share understandings
• Discuss choices with the Product Owner
• Break down large backlog items

The result is that the Team does not have shared understanding and awesome Product Backlog they instead fly by the seat of their pants during the Sprint. Since they don't have a shared understanding it is difficult for them to really understand what they need to do to deliver Backlog Items, and thus don't have good Estimates. Without good Estimates they don't know how much work they can Forecast...

Pretty messy... but easy to fix.

Refinement

You should be estimating in Refinement. This will allow you time to:

• Break down large backlog items when identified
• Identify unknowns that need to be investigated
• Discuss and share understandings

You have up to 10% of your Sprint for Refinement. Walk into your Sprint Planning with a fully Refined Product Backlog and a shared understanding of what you will be working on next.

Sprint Planning

If you have a shared understanding of a Refined and Ready Product Backlog then your Sprint Planning should be a breeze.

1. Refine any new Backlog Items added and prioritised from the Sprint Review
2. Product Owner presents his vision for the Sprint
3. Development Team & The Product Owner craft a Sprint Goal
4. Development Team selects the Product Backlog items that it believes that it can implement to reach the Sprint Goal.
5. The Development Team creates a Plan (in the form of a Sprint Backlog) to complete the forecasted Backlog Items.

If you finish that in 30 min then awesome! A timebox is a maximum and not a minimum so move on to creating software.

Conclusion

Take the time to Refine up front and then you don't need to spend 3 hours in Sprint Planning. But maybe, with the new information, they will get more engaged in creating the implementation plan.

Answer 4

I tried once printing out all the items to be estimated, dealing them out so everyone had an equal number, and spending 5-10 min during which people silently placed their cards in XS/S/M/L/XL columns on the table.

Then 5 min in which, if you disagreed about which column something was in, you put a token on it.

Everything without a token is done: take them off the table. Then have the discussions about where the rest belong.

We didn't find it useful enough to repeat, but it was worth trying, and it had the engaging "manipulate physical objects" aspect.

Answer 5

TL;DR- I use an exercise that can estimate 50 stories in less than 30 minutes. You can read the blog on how to play the game or you can download my training module for how to team it here.

I dislike planning poker for a number of reasons. I go into details on my blog post from March of 2012, Don't Play Planning Poker with the Gorilla. The short form is that it takes a lot longer, is less accurate and makes it easy for "experts" to sway the decision process.

Edit- Per request a short, short synopsis. First off, Steve Bockman has an eBook on Amazon that goes into how to do Team Estimation. My exercise is an evolution of Steve's.

Round 1: Stack of Fruit You start with a stack of cards. For the exercise, it's about ten cards with the name of a fruit on it. The team stands around a table and hand the stack of cards from person to person. Each person can do one of two actions, either place a card on the table, indicating if it is more or less effort than an existing card or they may move a card already on the table. When you are done you have a single row of cards from least effort to most effort (You can do this with business value as well). Round 2: Assign Points At this point you can break out the Fibonacci cards. The lowest effort fruit card has the 1pt card put over it. From here each person takes the next numbered card and places it down using the guidance of "Is this fruit card roughly 1.5 more effort to prepare and consume than the fruit card to the left."

When you are done, you have all the stories pointed in relation to the other stories.

There is also a round three, for what to do when you already have estimated stories.