15 Questions – Markers of Quality Sprint Planning Sessions
Curious how to put a coaching point-of-view on evaluating a Sprint Planning session? Our team uses the following set of 15 questions to gather observations and assess trends over time.
- What Sprint is it?
- Were All Team members present?
- How long was the session planned for?
- How long did the session take?
- Were ALL team members engaged and committed to the outcome?
- Was the Product Owner available, engaged, and committed to the team’s success?
- Were backlog items refined and ready for Sprint Planning?
- Did the team define a sprint goal (or theme)?
- Did the team define capacity in hours?
- Did team members break down each backlog item into a detailed task plan?
- Were tasks right-sized to start and finish in a day?
- Did the team rationalize capacity against detailed task estimates?
- Did the team commit to their Sprint Plan?
- Did the team proactively identify dependencies among tasks?
- Did the team proactively identify potential impediments that may occur during the sprint?
A little commentary about each question…
What Sprint is it?
e.g. Sprint 4 This is important to track so that you can associate these observations to other metrics and information.
Were All Team members present?
When considering this, think about not only attendance of team members, but the appropriate co-location. The commitment made during Sprint Planning should be made collectively by all team members.
How long was the session planned for?
This is most likely tracked in hours, rounded to the nearest quarter hour. More mature teams will not need as long for a Sprint Planning session, however, new team may take as many as 4-6 hours to complete the session. Keep in mind, if you are planning for the session to last 5-6 hours, be sure to allow for a break.
Teams that have well-refined backlogs do not generally take more than 1-2 hours for Sprint Planning. When sessions run longer, that is an indication that backlog items are not ‘ready.’
How long did the session take?
Again, track this in hours, rounded to the nearest quarter hour. Look for trends such as consistently running over, or not taking up all the time allotted. Just because a session is planned for 4 hours, doesn’t mean you have to use all 4 hours. It’s finished with the objectives have been achieved. And don’t forget, its OK for the session to be longer than expected. The entire team needs to agree to extending the duration.
Were ALL team members engaged and committed to the outcome?
Each team member should participate in this session equally. Here we are interested in understanding if team members are committed to the desired outcome from the Sprint Planning session.
Was the Product Owner available, engaged, and committed to the team’s success?
Sprint Planning is essentially the moment a backlog item’s scope is locked down. As team members identify tasks it is inevitable that final questions will come up in relation to acceptance criteria and what is in-scope for the story. As a result, the Product Owner should be available and engaged in the session to ensure the team is constructing a plan for the right product increment.
Were backlog items refined and ready for Sprint Planning?
“Ready” for Sprint Planning can mean a lot of things. e.g. Backlog Items: are written in good form; have Acceptance Criteria that define the Product Owner’s needs; are discussed and understood by the Team; are decomposed from Epics into small Stories that can be delivered in one Sprint; are estimated by the Team in Story Points; are prioritized in rank-order by the Product Owner; have needed supporting documentation.
Check-out this previous blog post on what ‘ready’ means: Getting a Story “Ready”
Did the team define a sprint goal (or theme)?
e.g. Complete the registration feature. A sprint flows well when the work is synergistic. If all backlog items are somewhat related then the tasks will naturally coordinate and the team will encounter less context switching as the sprint progresses.
Did the team define capacity in hours?
Before the session starts, team members should have thought through their individual capacity to commit to work. The determination should take into account planned vacation, non-team meetings and events, team collaboration and planning sessions as well as natural inefficiencies in work (about 20%). The facilitator (likely ScrumMaster) can then sum the numbers to determine the total team capacity.
Check-out the Capacity Planning worksheet within our Agile Tool-Kit to help team members think through their individual capacity in advance of the Sprint Planning session.
Did team members break down each backlog item into a detailed task plan?
Backlog items are historically decomposed into individual tasks. Ensure that enough tasks are planned to cover all items called for by the team’s Definition of Done. While backlog items are sized relatively using points, tasks should be estimated in hours in order to enable a team to make authentic commitments. This list of backlog items, tasks, and hour-estimates becomes the team’s Sprint Backlog or Sprint Plan.
Were tasks right-sized to start and finish in a day?
Humans are naturally inefficient creatures. So its safe to say that an 8-hour task will take more than 1-day to complete. Shoot for breaking down tasks to a 4-6 hour increment so that team members can commit and complete each day during the Daily Stand-Up. At most, use a 12-hour task (2-days of work).
Did the team rationalize capacity against detailed task estimates?
Consider responses like: On Target, Over-committed, and Under-committed. Sprint Planning is not magical, and teams should not waste time trying to make capacity and task estimates match up exactly. The goal is to best utilize the capacity available and avoid overcommitment as much as possible. Try to always come within 5-8% of the team’s capacity.
Look for an upcoming Agile Q&A Post about what to do with extra capacity.
Did the team commit to their Sprint Plan?
The ultimate objective of a Sprint Planning session is a commitment to deliver an increment of work. At the end of the session Team Members should look at the holistic plan and make an official commitment to deliver.
There are 2 aspects of the commitment. 1) Team Members committing to one another that they are going to band together to get the work done. 2) Team Members committing to the Product Owner that they will have something ready to demonstrate at the end of the iteration.
Did the team proactively identify dependencies among tasks?
Whether they are dependencies between tasks or external dependencies with other groups and teams, the identification and tracking of dependencies associated with the sprint is critical to success. In fact, looking at the critical path of tasks for each backlog item and analyzing dependencies will help a team further assess whether or not they are making a realistic commitment.
Here is a quick tip: For critical tasks, assign a “Must Start By” date. This will help know if stories with dependencies are on-track for closing out the backlog item.
Did the team proactively identify potential impediments that may occur during the sprint?
Teams that think ahead about impediments are less likely to encounter them. Experience tells us that task planning naturally uncovers potential impediments. It’s best to go ahead and capture that list so that you can work to resolve them before they even occur.