I took over 5 hours in sprint planning for a week long sprint. That seems like too much.
We discuss things in detail in sprint planning, as most of team members are not senior. If we don't it will lead to mistakes during implementation and redesign during sprint.
How do we deal with this?
How much detail should I discuss during planning to fit it to just 2 hours long per a week sprint?
Best Answer
You're right - 5 hours in Sprint Planning for a 1 week Sprint does seem like a long time. The Scrum Guide time-boxes Sprint Planning to 8 hours for 1 month Sprints and says that "for shorter Sprints, the event is usually shorter". If you consider the ratio, a good target may be 2 hours of Sprint Planning for a 1 week Sprint, but there's no fixed timebox.
So, how can you address a long Sprint Planning?
As a Scrum Master, I would take these following steps:
First, I'd work with the Product Owner to make sure that the Product Backlog is properly ordered. It is essential to effective Backlog Refinement and Sprint Planning to make sure that the most important work and their dependencies are at the top of the Product Backlog so that way the Scrum Team can focus their energies on defining, refining, and preparing the right work.
Second, I'd make sure that the team is spending sufficient time on Backlog Refinement. The Scrum Guide indicates that refinement activities generally take no more than 10% of a Development Team's capacity. As an example, a Development Team of 4 working a standard 40 hour week should plan on about 16 hours of Backlog Refinement. This may be done individually, in small groups, or as a team. I've found that having a planned Backlog Refinement session for the team and then breaking out to do any research or investigation or planning tends to work the best.
Third, make sure that the team realizes that they don't need to get every detail right in Sprint Planning. The goal of Sprint Planning is to produce a plan to completing the Sprint Goals. Don't try to do big design up front at a Sprint Planning session. Understand how different work fits in, dependencies, and objectives and use time outside of the Sprint Planning sessions with the right people to do the design, implementation, and testing required to deliver the work.
More steps may fall out of these, but this would be a good starting point.