Take the 2-minute tour ×


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.


How can we make the meetings more enjoyable?


Some more details, in response to requests for more information:


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?

  1. Meetings are long.





To sum up the question:

  • What are we doing wrong?


share|improve this question
@Jacob Spire: SCRUM is not well-accepted by all teams: in some teams it can improve communication and sprint planning can be a funny activity, other teams may have the feeling they are wasting their time speaking about what they have to do instead of actually doing it, so they probably do not enjoy sprint planning and other meetings. Try to understand if the team has some real problems with your process and do not force them to adopt a process that does not fit them. Just my 2 cents. –  Giorgio Jul 15 '13 at 16:31
Just curious, how would you rate the quality of your planning? Not that you shouldn't try to make it as enjoyable as possible, you have to get the job done. –  JeffO Jul 15 '13 at 20:56
@JacobSpire Attempted to answer some of your new questions from the edit. –  Ampt Jul 17 '13 at 18:56
How long are your sprints? Is the bigger problem identifying the tasks, or accurately estimating the tasks? Is part of the problem that the user stories are too ambiguous? –  Aaron Kurtzhals Jul 17 '13 at 19:12
What is the size of your team? Exactly how many stories are developed on during a sprint? How long are the sprints? If you think you're doing too many stories, then maybe one team could be split into two, or the duration of the sprints could be shortened? Help focus on less stories? It's not that you're doing something wrong, it's that something isn't quite fitting the way your team works. The retro should review what could change and try it in the next sprint. The team should help fix the process, not us. :) As much as we want to help. –  EdH Jul 19 '13 at 5:54

7 Answers 7

up vote 26 down vote accepted

Make estimating easier

Break your sprint planning down.

Do you need to estimate the individual tasks? I've done sprint planning two ways:

  1. Stories are estimated in story points and then tasks are estimated in hours
  2. Stories are estimated in story points and tasks simply fall under that with no estimate

Of the two, I prefer the second option. I find that not estimating tasks gives more freedom to developers to cope with changes. If a task no longer makes sense (how many times have you found out that a task isn't applicable or was already done in a previous sprint) you simply throw it out without any penalty, or you may have to change a current task into something new, possibly breaking it up. You're really being redundant if you estimate both, as the sum of the tasks should represent the story points and vice versa. What value do you really gain by this other than knowing how much time individual tasks will take? If you find yourself with task sizes that really vary enough to make a difference, I would suggest breaking those tasks down into smaller, more homogeneous chunks.

By doing this, you can cut down on the time you spend in sprint planning. Stories get estimated during sprint planning, and when you start the sprint you can put down all the tasks you can think of that make up that story. Obviously if there are points that you come across in estimating the story that you know will have to be dealt with in a task, you can add that onto the story information and put it as a task.

Estimate in Ideal units

Story points are meant to be in ideal units such as ideal man hours or ideal work days. These are meant to mean that given the perfect day every day, where you had no interruptions, no meetings, and everything went according to plan, you could accomplish the task in X days. Now everyone knows that this simply isn't true, but the wonderful thing about statistics is that it doesn't have to be.

What I mean by this is that after a while of estimating these in ideal days, you realize that maybe it takes an extra 25% of the time you estimate on average to complete a story. Lets say you had estimated 4 ideal work days, and instead it took you 5. Over time, you keep track of this and then you have a rough idea of the conversion from ideal days to real days. Your first instinct would be to try and compensate for this by over estimating, and you would likely be wrong. The main thing here is to stay consistent. That way, your long term average remains the same. Sure sometimes, it'll be under and sometimes it'll be over, but the more you estimate, the better off you are. If you find that you still can't get a decent estimate, maybe that means you don't know enough about the story to estimate it properly.

Talk about the stories

When you estimate, everyone should have a rough idea of what will need to be done, from start to finish, of what it will take for this story to be complete. You don't need to know every detail, but enough that you think you, yourself, could undertake the story. If you don't have that level of confidence, you probably shouldn't be estimating it. If you say "Well this story is too big for us to know most of the details" then that's an indication that the story is too big, and should be broken down. Stories, at least in my experience, have been small enough that one person, if need be, could work on it alone and accomplish it within a week or two.

This also will help to solve your second point in the edit, which is too much estimation. Instead of estimating every single task for every single story, you simply estimate the story as a whole, which should help to remove a lot of the estimating. As for making the meetings less monotonous, I would suggest planning poker, which you can see more information about above.

Make planning more engaging

Estimate using Planning Poker

As far as making estimation more fun, have you tried planning poker? It's the way that I've always done planning for all my sprints on multiple teams, and it's a good way to keep everyone involved, as every person has to at least pick SOMETHING. There's also a fair amount of fun involved when everyone on the team picks 3, and someone puts down a 20 and has to explain themselves, or when everyone on the team puts down a 5 but the manager puts down an 8 (who's gonna argue with the boss when he wants to give you more time!).

To do this, all you need are some planning poker cards, which we often make on the back side of index cards, or using normal playing cards with values attached to face cards. Nothing fancy, and it keeps everyone focused. Just remember that trying to do any task for an entire day (including planning poker) takes a toll on productivity. Many sets of cards come with a coffee card for a reason; if someone is feeling burnt out, give the team a break to recharge and pick it up when everyone is fresh!

As an alternative to physical cards, you could also look at electronic cards. The real benefits here are automated tracking of results, tracking user stories to be estimated and allowing everyone to show their cards at once to avoid "cheating" (where one persons estimate is influenced by another's due to being able to see their card). Obviously this requires everyone have a computer and the ability to focus on the task at hand though, so use it at your own discretion.

share|improve this answer
When using physical cards, we just placed them face down on the table to "lock in our vote" –  Wayne Werner Oct 28 '13 at 11:32
@WayneWerner We do that here too but some of our card sets often get used to the point of being transparent! –  Ampt Oct 28 '13 at 15:41
Cards, in my opinion, do nothing to make a tedious planning meeting any less painful. –  Andrew Medico May 7 at 17:30
@AndrewMedico I'd be interested to hear what you spend the majority of your time on? Are you spending a lot of time figuring out what a feature means? Or attempting to come up with a solution right there? I've got a feeling that you're using the planning meeting as an attempt at getting everyone together to solve the problems, instead of simply planning how long it will take to solve them. –  Ampt May 7 at 17:34
  1. Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too.



So in summary - quit wasting people's time and they'll dread the meetings a bit less. Beyond that, fun and comradarie in the team isn't something you can address in meetings. Go to lunch together, joke around, mix people up to have better personality fits, have mustache growing contests... once the morale is up then people will naturally make sprint planning meetings more lighthearted.

share|improve this answer
You're making a lot of assumptions that may not play into how Scrum is done at the OP's company. In Scrum, as written, there are not "team leads" nor "QA people." Moreover, you don't know how granular the user stories are and the team's capabilities--they may handle 1 story a sprint or 15, I don't know. Yes, you can prep stuff to minimize the work needed in the meeting--that's decent advice. –  Matthew Flynn Jul 15 '13 at 15:50
@MatthewFlynn - I am absolutely making some assumptions. In my experience they're fairly reasonable ones, and what I've seen in companies with non-dreadful sprint kickoffs. I hope that readers are adept enough to adapt to their environments. –  Telastyn Jul 15 '13 at 17:34




We hold our sprint planning and retrospective at the same time, and are almost always done in 90 minutes, but we are one of the faster teams. We do a big company-wide longer-term planning every 5 sprints that takes 4-6 hours. Every team is different, of course, but if you're spending an entire day every sprint, there's a lot of room for improvement.

share|improve this answer

Your planning sessions are way too long!



A way that worked for me:

  • Quick intro to the sprint by the PO
  • Estimation of the sprint capacity
  • Official commitment/forecast by the team


share|improve this answer
of course, if your rule of thumb is correct and you spend 2 hours per week, if the OP has 4 week sprints, sprint planning should take 8 hours. That would contradict your "Your planning sessions are way too long" comment. You might want to rephrase a little to clarify (for example, mention that your "too long" comment only applies to 2 week sprints). –  Bryan Oakley Jul 15 '13 at 16:12
Correct, I will rephrase. –  Ebenezer Sklivvze Jul 15 '13 at 16:12
In particular, my 2 week planning meetings with the agenda above lasted for about half the time so I've changed to reflect this. –  Ebenezer Sklivvze Jul 15 '13 at 16:14
Our 2-week sprints are planned to take 4 hours for planning (they sometimes end up a bit more, sometimes a bit less), so that does seem like a good general rule-of-thumb. –  Izkata Jul 15 '13 at 18:55
FWIW, my company typically schedules 2 hours for planning a two-week sprint. My current team usually knocks it out in about an hour. –  Bryan Oakley Jul 15 '13 at 19:30

At my previous job, the entire first day of each sprint (we called them iterations there) was taken up with:

  • Retrospective. We started out doing this in the afternoon of the last day, but we often found ourselves retrospecting about the sprint and then going back to work tying up the last loose ends of that sprint's work, so we figured it would be better to make sure the work was all behind us before retrospecting on it. It also seemed logical to consolidate all the meeting overhead of the Scrum process so the other days could be planned and spent in more ideal terms. This typically took 2 hours.
  • Sprint Planning. The backlog was estimated during a Milestone Planning Meeting (which could be an entire day in itself for both the Devs and POs), and had been prioritized by the POs prior to the beginning of each sprint. We figured out how many developer-days we had available (accounting for holidays, vaca, etc), grabbed the work we thought we could do off the top of the pile, and quickly reviewed the user requirements (previously vetted by our BAs) to get a more complete sense of what the work entailed than we got with the simple overview during the MPM. This typically took another 2 hours.
  • Task Planning. Knowing the stories and acceptance criteria, we broke down each story into bite-size tasks estimated in ideal hours (an hour spent focused solely on getting that task "done" with no distractions or roadblocks). The way our point scale ended up being calibrated, a 5 was a developer-sprint, so a 1 could be anything up to and including two developer-days. For that reason, virtually everything had to be broken down in order for team members to be able to show progress on the scrum board. This was another 2-hour block, with some give-and-take between this and the next item.
  • AAT Outlining. Our POs and BAs were not programmers and did not code. The POs hid behind a contract stipulating that they would deliver requirements in the form of a Word template and would work with the BAs to refine them in that form. BAs understood code, but their time was purely analysis and final testing (which required the system to exist, so they could record their macros into Selenium). So, to verify that our code would meet acceptance criteria when it came to that, we had to write our own AATs modelling the actions of the "paper" acceptance test. We typically did this in the same NUnit framework we used for unit and integration tests (we tried FitNesse and couldn't give it up fast enough). This was the rest of our first day of each sprint and continued into the second.

In my current job, we're still adopting the Scrum process, we didn't have a team-wide milestone planning, and a lot of what we're working on doesn't have strict acceptance criteria. So, our sprint planning is as much an explanation of what each story entails and what we'll call done as it is a commitment to grab the top X ideal hours of work off the top. We get away with it - for now at least - because we're an in-house team and each of us works personally with the end users of our software to gather requirements and design solutions. Even then, sprint planning is an all-morning thing every other Monday, and the afternoon is spent clearing any personal roadblocks to being able to start development in earnest on Tuesday.

To actually answer the OP's question rather than contrasting other comments/answers saying it shouldn't be taking that long, there are ways to approach Agile estimation, sprint planning and retrospectives that are a little more interesting than you might be using.

Specifically addressing your concerns:

  • Meetings are long - Time-box them. Each meeting, be it a retrospective, sprint planning, task breakdown, etc, should have a definite purpose and topic of discussion, and should be limited as much as possible to a set amount of time. It's the Scrum Master's job to keep these meetings on topic and rolling along to meet the time goals.

  • Meetings are monotonous - There will be some of that; you're working in bite-size chunks, one at a time, so you'll be doing the same thing over and over. Keeping the team focused and driving toward accomplishing the purpose of the meeting will help.

    Something else I hear is that maybe your sprint planning meetings are trying to accomplish too much. At my last company, story estimation was done at "milestone planning meetings", which happened about once a quarter and took all day. In those meetings, everything that had built up on the backlog that we hadn't estimated was estimated in points. If you're doing story estimation in points, and then task estimation in hours, you don't want to do them both at the same time (maybe on the same day).

  • Estimating stories in points, then tasks in hours seems redundant - They have two different purposes. The purpose of story estimation is to provide a rough estimate of complexity, that you can use to fill your sprint backlog based on past velocity and expected bandwidth. The purpose of task estimation is to break the stories down into things that take one developer-day or less (and so can be assigned to a single guy who would be expected to have it all done in time), and ensure you haven't mis-estimated any story's complexity nor bitten off more than you can chew in the sprint.

    If your stories all take one day or less, then it is redundant, but not all points scales are calibrated equally; at my last job, a 5 was two developer-weeks (because at the beginning we had a lot of epics to estimate), which on a linear scale made a point anything up to 2 developer-days. Given that kind of scale, virtually everything should get broken down into tasks. At my new company, a point is closer to half a developer day, so a 1 or even a 2 is definitely its own task, and 3-8 is nebulous with regard to forcing the team to split it up into tasks.

  • There's a vicious cycle of it taking longer making people less focused so it takes longer - Time-box your time-box. Take breaks, just like you should be when coding. Every 30 minutes, take 5 minutes to stretch your legs, regroup, etc. You can make it ten minutes every hour, but don't push a solid block of meeting time too much further than that. Your guys might be getting hungry, or need more coffee, or a bathroom break, etc. Don't deny them; if you make them suck it up you'll find their minds wandering. Beyond that, keeping discussions short, sweet and to the point will help as well, as previously mentioned.

share|improve this answer

The Sprint planning meeting has 2 parts:

  1. Decide what the team will do
  2. Decide how the team will do it.

The first part is relatively straight forward--based on the number of story points the team feels they can take on, the commit to completing that many user stories in their order of priority. Done.

The second part is what developers should actually enjoy--elaboration of the story and designing the solution. The tasks fall out of that. So, have the product owner, or whatever SME he has provided explain a chosen story. Then have whichever developer wants to take it on, lead the design discussion. Use a white board. Bounce ideas around. Have fun.

That's it, really. If design meetings aren't fun, then there's just something plain wrong.

share|improve this answer

We are having a weekly sprint with a one hour meeting in which we discuss the previous sprint, what is left to do and then move on to the planning of coming week. All within one hour.

This is of course because we found out that in our case following scrum too strictly would only waste too much time. That is because most stories are already discussed with our team members when the requester creates the user story.

I'm just saying that if your team dreads planning meetings, you should probably let go some of the "rules" of scrum.

share|improve this answer

protected by Thomas Owens Oct 28 '13 at 19:27


Would you like to answer one of these unanswered questions instead?
