Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

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
3  
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
up vote 22 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
3  
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
4  
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
    
@MatthewFlynn good point – Hossein Aarabi Mar 20 '14 at 5:53
    
In my team of 3, we usually only had half-hour long sprints, and when the team was 7, it was usually only an hour for two week long sprints. – Zymus Mar 12 at 18:31

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
2  
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

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
1  
Why not start the process as designed and adapt from there? If you decide to use agile practices and haven't molded your business in that direction, you're already in trouble. – JeffO Mar 18 at 21:09

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

In Scrum, when working to 2 week sprints, the sprint planning is time-boxed at 4 hours, making it a half day event. One reason for the relatively large amount of time is that the development team must be able to confidently agree that all items being pulled into the sprint backlog can be delivered, which means they need to know the detail. It is not uncommon as part of sprint planning for teams to break off from the meeting space for periods of time in order to investigate items further and ensure that they are "Ready" to go into the sprint backlog. (It can help to think of sprint planning as an event, rather than a meeting.)

Use your "Definition of Ready" and the length of time that the sprint planning event allows to ensure that all backlog items going into the sprint are both feasible and ready. i.e. They can be done (completely, as per "Definition of Done") within the sprint, and there is enough information for the team to be able to do them right now.
Note of course that you probably don't want to be doing this for ALL items during the sprint planning, as it can be very time consuming. Do try and have regular backlog grooming (outwith sprint planning) where you can breakdown backlog items, and estimate items not yet estimated using planning poker for example. (I've found this can be a effective activity for over a working dinner with the development team, should you have the luxury of your team's availability at dinner time!)

High priority items can often be added to the product backlog by the product owner just prior to sprint planning though, and whilst routine backlog grooming can, and normally should, be done before the sprint planning event, there will always be new items like this where the team needs to spend time working out the detail and estimating complexity during the sprint planning event, hence why it can stretch to 4 hours for 10 day/2 week sprints.

If you need to take longer discussions out of this event, then you might have a backlog item in the sprint backlog to "have such and such a discussion to establish x", but you should avoid including sprint items to do whatever you are going to determine needs done during that discussion, as those are not "ready" backlog items to go into the sprint.

As people have said, there are reasons you might want to change the way you run Scrum if the process isn't working effectively for you. Scrum is however, a very well thought out and tested framework to start with so I would make sure your reasoning is justified before changing the process.

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.