Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite
1

In your experience, how long should a planning meeting (SCRUM) last? 8 hours? Or should it be shorter (succinct) and further discussions should be planned as part of the sprint (10 days sprint)?

share|improve this question
2  
8 hours per a 10 day sprint definitely sounds too much to me. Discussions which don't require the whole team should be taken out into separate sessions, only for the members involved. – Péter Török Sep 13 '11 at 15:19
1  
So you plan other meetings instead of discussing everything in the planning. Point noted. – wleao Sep 13 '11 at 16:14

4 Answers

up vote 10 down vote accepted

According to the Scrum Guide:

The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.

That generally works for me.

share|improve this answer
Thank you, I'm going to read it. – wleao Sep 13 '11 at 16:00
That's probably a good starting point, but it should also be noted that you do need to tailor the process to your project, team, and organization so that it works for you. Just because other people have had luck with it doesn't mean it will work for you right out of the box. – Thomas Owens♦ Sep 13 '11 at 20:21
However, if you're going to try Scrum, you should probably try it based on the defined guidelines first. Then, if something isn't working, refine it. If you change the rules before you even start, you're disregarding the empirical evidence that made the folks who devised Scrum recommend what they recommended--without any empirical evidence to show that that's the wrong thing for you. – Matthew Flynn Sep 14 '11 at 17:10
up vote 9 down vote

As long as it needs to last, no less and no more. Anything else isn't Agile.

If you have a team of 2 - 3 developers and are doing 1 week sprints anything more than a hour is probably counter productive.

If you have a team of 15 people and 2 weeks sprints you are looking at all day, anything less isn't detailed enough.

It takes experience to get it mostly right, and that is what retrospectives are for, the team decides what is too long or too short.

Don't worry about getting it perfect or sticking to what some book says, try something and refine it.

SCRUM is about refining the process in iterations as much as it is about refining your code in iterations.

share|improve this answer
An hour seems a bit short for 3 developers / 1 week sprints. Then again, I just finished a relatively small project where we did a 5-minute weekly sprint planning. It depends on the project, and on the cards, because sometimes more (or less) discussion is needed during sprint planning. – configurator Sep 13 '11 at 18:15
One of the key ideas of Scrum, as an Agile framework, is that you <i>time-box</i> activities, such as the sprint, the sprint planning meeting, and the daily stand-up/scrum. The point is to keep things focused. Time-boxing does not mean that you cannot take less time than is designated. Just that you should not take more, as that tends to make people lose focus and also reduces the amount of time the team has to actually do the work. – Matthew Flynn Sep 14 '11 at 17:14
up vote 3 down vote

Do not mold your business around the process. The process supports your business. The moment you're doing process for its own sake it's time for the process to get the axe. To that end, there is no "right" way. Meetings should only go as long as you are accomplishing something in them. If it takes you 30 minutes or 4 hours, as long as it works then go with it. Ignore what some book/blog/coach tells you and do what is right for you.

share|improve this answer
up vote 0 down vote

Take as long as you need so that you select enough that your team thinks they can reasonably achieve in the sprint. But you should be spending time during the (previous) sprint refining the backlog: estimating and refining stories.

From the Scrum Primer (PDF):

Product Backlog Refinement

One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the Team to refining (or “grooming”) the Product Backlog. This includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Scrum is silent on how this work is done, but a frequently used technique is a focused workshop near the end of the Sprint, so that the Team and Product Owner can dedicate themselves to this work without interruption. For a two-week Sprint, five percent of the duration implies that each Sprint there is a half-day Product Backlog Refinement workshop. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. With this practice, Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items. A sign that this refinement workshop is not being done (or not being done well) is that Sprint Planning involves significant questions, discovery, or confusion and feels incomplete; planning work then often spills over into the Sprint itself, which is typically not desirable.

Doing this means you can focus on planning during planning, and it doesn't take all day and the team starts to lose focus and get bored.

share|improve this answer

Your Answer

 
discard

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.