Why is sprint planning so long if your backlog is ready and prioritized



  • 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?



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2