How to make sprint planning fun
- by Jacob Spire
Not only are our sprint planning meetings not fun, they're downright dreadful.
The meetings are tedious, and boring, and take forever (a day, but it feels like a lot longer).
The developers complain about it, and dread upcoming plannings.
Our routine is pretty standard (user story inserted into sprint backlog by priority story is taken apart to tasks tasks are estimated in hours repeat), and I can't figure out what we're doing wrong.
How can we make the meetings more enjoyable?
...
Some more details, in response to requests for more information:
Why are the backlog items not inserted and prioritized before sprint kickoff?
User stories are indeed prioritized; we have no idea how long they'll take until we break them down into tasks! From the (excellent) answers here, I see that maybe we shouldn't estimate tasks at all, only the user stories. The reason we estimate tasks (and not stories) is because we've been getting story-estimates terribly wrong -- but I guess that's the subject for an altogether different question.
Why are developers complaining?
Meetings are long.
Meetings are monotonous. Story after story, task after task, struggling (yes, struggling) to estimate how long it will take and what it involves.
Estimating tasks makes user-story-estimation seem pointless.
The longer the meeting, the less focus in the room. The less focused colleagues are, the longer the meeting takes. A recursive hate-spiral develops. We've considered splitting the meeting into two days in order to keep people focused, but the developers wouldn't hear of it. One day of planning is bad enough; now we'll have two?!
Part of our problem is that we go into very small detail (in order to get more accurate estimations). But when we estimate roughly, we go way off the mark!
To sum up the question:
What are we doing wrong?
What additional ways are there to make the meeting generally more enjoyable?
