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)?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
According to the Scrum Guide:
That generally works for me.
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.
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.
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):
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.
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.
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.