Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been in several projects using scrum now.

The length of the sprint review and/or retrospective has varied from client to client, from project to project. Some of the reviews became too long (2 days).

Sometimes, I've lost focus while being in this long meetings and just wanted to go back to my safe and happy place (my chair in front of my computer).

What is the ideal length of these meetings? What's the best way to avoid long meetings?

share|improve this question
up vote 4 down vote accepted

In my experience, sprint planning usually takes half a day for a two-week sprint on a complicated project with clients who don't really know what they're doing. Obviously, with a smart, experienced team it's usually quicker.

Sprint planning time doesn't scale linearly, though - a four-week sprint generally doesn't take a full day to plan and a one-week sprint will still take about the same amount of time as a two-week one.

Sprint reviews should only really take an hour or two; half a day at absolute maximum. Remember, you're demonstrating what you've built. Even Microsoft launching a new flavour of Windows doesn't run full-day demos - people switch off and get bored.

Your sprint retrospective should be something that your team does after everyone else has left. Consider it akin to sitting back with [coffee/beer/hard liquor of choice] and asking yourselves how you did. It's not supposed to be a formal, minuted discussion - rather, it's an opportunity to genuinely reflect on recent events. An hour maximum in my opinion, and usually closer to 20 minutes.

share|improve this answer
I shall show this answer to my teammates :) – Edgar Gonzalez Apr 28 '11 at 4:34
I do not understand why this is the chosen answer because the suggestion about Sprint Retrospective is very much off. Sprint retrospective is the second most important meeting in the whole Scrum process. This is the only meeting where the teams has a chance to improve itself and become truly great, so by having only 20 minutes for it you leave your team in a constant state of mediocrity. – GEMI Jan 26 '15 at 14:39
If your team is struggling and you only have a 20-minute retrospective then yes, that's insufficient. If it's a high-performance team which has been working well together then that amount is plenty. Do what works. Change what doesn't. – uglybugger Feb 6 '15 at 11:43
But most teams are probably not going to be high performing, so suggesting in general a meeting length only appropriate for one is bad. – Andy Nov 16 '15 at 0:03

The Sprint retro is meant to be a time to reflect on the progress made and to also fine tune your process. If you have a 1 month (4 week) sprint capping it with a day for review a day for retro and a day for planning is the norm. With a shorter sprint (2 week) you should be able to retro and review in less time: half a day for review, half a day for retrospective. Planning is going to be a day long affair no matter how you put it. (If nothing else than to give the team a few hours to recover from planning which can be more exhausting than any other activity).

I avoided saying it until now, but there's a way to hack the system, consider going Lean

share|improve this answer

It depends on when you last held the meeting. My rule of thumb is one to two hours per week.

So a meeting for two a week sprint should be between two and four hours. That’s not a hard rule, but you should use at least an hour each time. It’s better to hold short meeting more often, rather than long meetings more seldom.

The reason for that is getting feedback quickly. I mean, after a month none will even remember what they did four weeks ago.

Also, remember to hold this meeting at regular intervals. Usually at the end of each week, month or sprint. You can also hold it at the end of a project or when you do a release or, well, when you need it.

share|improve this answer

Your Answer


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.