Skip to content

The agile meeting dilemma

February 29, 2008 by cspag

If you've been doing agile, and especially Scrum, you're well aware of the meetings that are required to keep things running smoothly: (1) the iteration planning session, (2) the daily stand ups, (3) the iteration review session, and (4) the iteration retrospective. If you follow scrum by the book, a two-week iteration would include 18 hours of meeting time (8 hours for planning, 15 minute daily stand ups, 4 hours for review and 4 hours for a retrospective). That's 22.5% of an 80-hour schedule for an iteration that is consumed by meetings. Many people argue that this is too much time spent in meetings over the lifetime of a project, especially if it's an overhead or operational expense. I don't necessarily disagree. However, these meetings are essential to effectively delivering value to clients and to the continuous improvement of a team's agile practices. So, how do you handle this dilemma of balancing meetings that enable practices with project budgets, etc.? The answer: Use the scrum mantra "Inspect and Adapt".

Our agile teams have examined our meetings and have effectively reduced our meeting time to the following: 2 hours for iteration planning, 15 minute daily stand-ups (and they're usually shorter than that), 1 hour for our iteration review (usually shorter) and 1 hour for a retrospective (again, usually shorter). This amounts to only 6 hours (or less) of meetings for every two week iteration or 7.5% of the iteration spent in meetings. We think this is a manageable amount of time to dedicate to the various necessary activities of scrum to be both efficient and effective. I think that anything shorter than these times would probably start affecting the value of these agile practices. We are still planning without any problems and we are able to review two weeks worth of work in 1 hour or less with our clients. We have also found that 1 hour is more than enough for our retrospectives. Currently, we include these meetings in our project costs because we bid our projects as agile projects. Our clients are aware of the value these meetings provide their final product.

So, based on our experience, I would suggest really examining the value of the meetings you use to keep your agile practices running. If you and your team find that you are merely filling up time-boxes to do scrum by the book, inspect and adapt. And remember, if you adapt your meeting times to be shorter and you are finding that you need more time for a review or for your planning session...inspect and adapt. Scrum is an imperical "process"...keep experimenting with your meeting times until it feels right for you, your team and your product owner. And, if you can agree with your client that these are project related costs that provide value and not overhead or operational costs, all the better for you and your client.

Comments

Actually, you're doing it by the book anyway

March 2, 2008 by Evan Wired (not verified), 3 years 48 weeks ago
Comment id: 1467

A "by the book" Scrum iteration is 30 days, not 2 weeks. Everything I've read in the Scrum literature suggests that if you shorten your iterations, you should scale the meetings accordingly (except the daily standing meeting, which is pretty much always timeboxed to 15 minutes). So, if you're cutting your sprints to 15 days, you should be spending half the time in planning and retrospective.

This scales way down, too. In the "59-minute scrum" exercise, all of the "meetings" there are proportional to the iteration length as well.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com