We are doing 2-week sprint. As per scrum guideline, 2-week sprint should not take more than 2 hours to complete.

However, sometimes we take more than 8 hours to complete SPM2. I'm sure something is going wrong here. Below are aspects we cover during SPM2.

  1. Technical Analysis
  2. Sometimes we also refer code to bring better clarity
  3. Breaking stories in to tasks

Most of the time consumed in step 1 & 2.

  1. As per scrum guide the sprint planning for a 2 week sprint should be timeboxed to about 4 hours. There's no mention of a second meeting but I've read that it used to be split into two meetings. So you shouldn't feel bad if you take more than 2 hours for your sprint planning. But the whole spring planning together still shouldn't take 8-10 hours...
  2. Improve your refinement. Depending on what exactly you do in step 1 and 2 you might want to transfer some of that work into the refinement process. Do you have a definition of ready? Could your backlog items be vertically subdivided further? (Ie. splitting "Account deletion" from "account management" to be done later is ok. But splitting "account deletion" into "UI design" and "backend implementation" is less so)
  3. Limit depth of SPM. You might be planning your backlog items in more details than necessary. Difficult to say without further information.
  4. Increase focus. Are you using time discussing topics that are not necessary for sprint planning?
  5. Improve documentation. Are your requirements and specifications up to scratch? Is your architecture self explanatory or documented well enough to give you a sufficient overview for planning?

Technically refinement can use up to 10% of your capacity. For two week sprints thats up to a full day. There's no specification when this is supposed to be done. So it's possible part of this has simply merged into your sprint planning.


The Scrum Guide

The Sprint Planning meeting has two topics, not two separate events.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

The event is not required to be shorter.

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

The effort of the Sprint should not be overly planned: the work emerges.

any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.

Be certain the the item is sufficiently understood by the Development Team prior to Sprint Planning. (See my answer to your other question.)

Vertical slicing(1, 2, 3) is an important technique for doing just enough of a feature to provide value. When the scope of the item is smaller it is more easily understood, decomposed, implemented, tested, and (ultimately) delivered.

Tasking is often a sign of an opportunity to improve collaboration. Individual pieces of work being determined and being addressed by individuals (especially in a development versus testing versus documentation manner) invites bugs and technical debt among other issues. Try pair programming in order to provide code review as work occurs and enable shared knowledge.


As a general rule, if sprint planning is taking too long then it is likely you are not doing enough backlog refinement.

Remember that teams should be spending something like 10% of their time in a sprint preparing for the next sprint. That means reviewing the backlog, discussing designs, etc.

Also, don't feel like you need to plan everything in a sprint during sprint planning. The intention is to draw out the key information, but you should also leave room in the sprint for unplanned or unexpected work. Mike Cohn describes this well here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.