Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. According to the scrum guide it sounds like the meeting has two parts: What can be done this Sprint and how will the chosen work get done

If your product backlog refinement is done well and all dependencies, priorities and acceptance criteria is ironed out, then we should be able to easily take items from the backlog to the sprint.

In part one of the sprint planning we can set the sprint goal and select the relevant items for the sprint. Part two of the meeting the how is already discussed in backlog refinement.

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

I understand there is a maximum timebox but not a minimum, so is it possible to have a short sprint planning meeting?

  • Of course it’s possible! Why do you think it’s not possible?
    – Peter K.
    Mar 24, 2020 at 9:56
  • One team I work with has a sprint planning session that lasts under 30 minutes. Mar 24, 2020 at 17:44

2 Answers 2


Concerning the timeboxes, they are all maximums. If you can accomplish the purpose of the event in less time, there's no reason to remain in it for longer. Your events - all of them - can be shorter than the timebox. The one thing to watch out for is rushing through events and missing the purposes and benefits.

Specifically about the Sprint Planning and backlog refinement, the how is not already discussed. Backlog refinement is more about figuring out what to build. There may be some high-level discussions of how, but the emphasis is on what the stakeholders need and not the details of how. If you do get into the details of how to build, you'll likely run into problems such as an excessive amount of time in refinement (which may simply be reallocating time from planning to refinement).

Consider this section of the Scrum Guide:

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. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

Refinement is about details, estimates, and order to items. Ordering often includes priority but also dependencies. Aside from splitting, there's little decomposition into the level of granularity that is associated with the planning. This granularity improves visibility into the Development Team's work during the Sprint.

I do want to be precise - there may be nothing wrong with what you are doing. It doesn't seem like it goes against anything in the Scrum Guide.


Yes – to maybe state it another way:

"Constructing and prioritizing the backlog" consists of mapping out the overall structure of the project, considering dependencies within the structure of the software itself, the list of steps probably needed to accomplish certain things, and so on. These are high-level project management and software design concerns. They are often under-appreciated and rather ineptly done. But they are critical!

"Now, a team is ready to get to work." The time-box idea is intended to help set the scope of this meeting, to avoid "analysis paralysis" and to help guide the team into choosing a set of goals that's "Mamma-Bear sized: not too big, not too little, just right." That will of course come with team experience.

I think that it is excellent that you are devoting so much time and effort into "backlog preparation," because in my experience this is where many teams go wrong. If you find that your teams can spend much less time "selecting tasks to sprint," and that they are able to consistently accomplish their goals each time, then those preparations and planning are the reason for your success. Keep it up!

Too-many teams, composed as they inevitably are of "experience 'pantsers,'" try to approach "sprint planning" by the seat of their pants, too. They don't invest their time in meticulous high-level planning, as your successful teams apparently do. No matter how "good" you think you are, you really can't develop software by the seat of your pants!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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