This blog post examines the fundamental guidelines to sprint planning meeting effectiveness based on my hands on experience as an agile coach.
I will be updating this list further as when I gain more insights about conducting effective sprint planning meetings.
Last updated on 08/Sep/2020
A well managed sprint planning meeting provides amble opportunities to discuss divergent views before converging on the best. This facilitates dialogue among the team members, which adds tremendous opportunity to learn from each other. This co-learning results in enhancement of the capability of the team. This in turn translates to better productivity.
Sprint planning meeting guidelines
- Duration of the sprint planning meeting – For a thirty days sprint we need eight hours for effective sprint planning. If that is the case, how much will it take if the sprint duration is two weeks?. The most common answer is ‘4’ hours. Believe me, sprint planning will take a minimum of 5 hours even if the sprint duration is 5 days. That is one of the reasons why very short sprints are not very effective. Plan for 5 to 8 hours for sprint planning meetings. That is a good investment. Very short sprint planning meetings are an indication of the command and control culture within the team, where a few decides and those decisions are imposed on to the team.
- Time boxing of the sprint planning meeting – As already discussed, the sprint planning meeting is time boxed into 5 – 8 hours depending on the sprint duration. The sprint planning meeting is further split into two logical halves of equal duration. The first segment is for selecting the sprint backlog from the product backlog. The second segment is for decomposing the sprint backlog further into the activities that need to be performed to build those features. and the second segment is for preparing the sprint back log.
- The Participants of the sprint planning meeting – The attendees are the scrum master, the product owner / product manager and the development team comprising of professionals with the required skills to build the product. Additional parties can be invited to provide additional business domain or technology domain information and advice, but they are dismissed after this information is provided.
- Product backlog readiness – Product backlog readiness is one of the key success factors for effective sprint planning. The product owner must elaborate the prioritized the product backlog (sprint backlog) to sufficient detail to enable the team to estimate the work. This where User stories helps. As a generally followed good practice, it will be useful if the product owner can prepare the user-stories at least for the features he/she is planning to schedule into the sprint. While elaborating the product backlog entries into user stories prior to the sprint planning meeting, the product owner will get sufficient opportunity to think though the feature to be developed in detail from the functionality perspective.
- Product backlog sharing – It works wonders, if the product owner can share the user stories of the upcoming sprint in advance to the development team. This has many advantages. This helps the team members to understand the functionality well even before walking into the sprint planning meeting. That will trigger the ‘How to do it’ thinking resulting in research before the planning meeting. This will also act as a peer review of the story before the actual planning meeting.
- Product manager availability – It is always advisable for the product manager to be present during the sprint planning meeting. In the absence of either the product owner or the product backlog, the scrum master is required to construct an adequate product backlog prior to the meeting and to stand in for the product owner, provided he has the capability and product vision.
- Sprint backlog – The goal of the first segment, or first 4 hours of the sprint planning meeting is for the team to select those product backlog items that it believes it can commit to turning into an increment of potentially shippable product functionality. The team will demonstrate this functionality to the product owner and stake holders at the sprint review meeting at the end of the sprint.
- The team can make suggestions, but the decision to what product backlog can constitute the sprint is the responsibility of the product owner.
- The team is responsible for determining how much of the product backlog that the product owner wants worked on the team will attempt to do during the sprint.
- Time boxing the first segment to 4 hours means that this is all of the time that is available for analyzing the product backlog. Further analysis must be performed during the sprint. Large-grained, high-priority product backlog with imprecise estimates might not be thoroughly understood during this part of the sprint planning meeting and might result in the team not being not able to complete all of the product backlog that it selects.
- The second segment of the sprint planning meeting occurs immediately after the first segment and is also time boxed to 4 hours.
- During the second half of the sprint planning meeting, the team;
- Identifies the activities that need to be performed to construct the features agreed upon during the first half of the sprint planning meeting.
- Estimate the effort required to complete these activities
- Validates with the available capacity and productivity to ensure that the team can build what is committed.
- The product owner must be available to the team during the second segment to answer questions that the team might have about the product backlog.
- It is up to the team acting solely on its own and without any direction from outside the team to figure out during the second segment how it will turn the selected product backlog into an increment of potentially shippable product functionality. No one else is allowed to do anything but observe or answer questions seeking further information.
- Sprint Planning Meeting Output – The output of the second segment of the sprint planning meeting is a list called sprint backlog, of tasks, task estimates and ‘volunteered work’ that will start the team on the work of developing the functionality. The task list might not be complete, but it must be complete enough to reflect mutual commitment on the part of all team members and to carry them through the first part of the sprint, while the team devises more tasks in the sprint backlog
Some of the key challenges of sprint planning meetings
- Under the pretext of lack of time, some of the senior members does all the estimation work and thrusts that upon the rest of the team.
- Lack of involvement of the team – Many team members do not participate well during the sprint planning meeting. At the same time I have seen many participating well as well. The root cause for lack of participation is lack of preparation. Still I remember the youngest engineer (had just 3 months work experience) who got introduced to me as ‘The most valuable engineer’ by the scrum master. He used to contact the product owner weeks before the sprint planning meeting to collect the probable features the product owner is planning for the next sprint. Then he starts R&D work on those features. By the time he enters the sprint planning meeting, he has a very good idea about the work that need to be performed to build those features. That is the right way to go.
- Insufficient preparation by the product owner prior to the sprint planning meeting. Because of this, very often the product owner is unable answer the team’s queries regarding functionality. Even though the scrum guide does not say anything about this, based on my experience, it will be better if the product owner could prepare the user stories for the features she is planning for the sprint before getting into the sprint planning meeting.
- Absence of the product owner during the sprint planning meeting. In this scenario, quite often the team will get struck during the sprint planning meeting due to lack of details.
- Insufficient clarity about the reason behind doing a size based estimate (story points), before arriving at the effort. Unless one have in-depth understanding of the scrum framework and empiricism there will be ambiguity between size estimates and effort estimates. Why cant we jump into effort estimates directly?. I will soon write a blog post to explain this in detail.