Sprint Planning: the Most Important Agile Ceremony

However, agility is essentially a workplace culture that turns the entire team’s focus on the project’s success. This subtle difference is summarized in this quote:

“There are two kinds of teams: the ones who DO agility and the ones who ARE agile.”

In this article, we look at the Sprint Planning, which in my experience is often deemed the least important ceremony. Sprint Planning is the key to transforming a team that fails its sprints into a top performer where all members develop professionally and enjoy their experience.

A Ceremony for Team Building

In too many cases, Sprint Planning is a short meeting in which the Product Owner (PO) or the Scrum Master decides the number of stories that will be included in the sprint, based on the estimated team velocity. These meetings last only 15 to 30 minutes and generally lead to failed sprints, low-quality code, team disengagement, and volatile commitment to the project or its success.

Instead, Sprint Planning should be the developers’ ceremony rather than the PO’s or the Scrum Master’s. It’s the moment when developers take matters in their own hands in view of the upcoming sprint. The PO and the Scrum Master are not excluded from the meeting, but they need to understand that their influence has to stay limited:

• The PO answers questions if needed.
• The Scrum Master ensures good practice.

Towards a Sense of Ownership

By taking control of the Sprint Planning, developers cultivate a sense of ownership that will lead to commitment, responsibility and accountability. This change is not caused by restrictions, hierarchical pressure, or apprehension, but because the team voluntarily commits to the delivery, and people inherently want to keep their word and succeed in creating superior quality products. The sprint is the team’s group effort, and the team obviously wants to be proud of it. All the practices we talk about further in this article help develop and anchor this mindset.

As mentioned earlier, Sprint Planning for many teams mainly consists in selecting a set of stories to reach a given number of points for the sprint. However, the purpose of the ceremony is to ensure a successful sprint by engaging the team and preventing miscommunication. To reduce the risk to a minimum, the team needs to share an understanding of each story in terms of :

• What it should accomplish;
• How it should be developed;
• How long it should take.

Time Over Points

To reduce the risk, the simplest method is to allow the team to divide each story into subtasks with a time estimate. Doing so benefits the team and the sprint in several ways:

• Listing the subtasks for a story lets the whole team see what should be done and how. New members to the team will quickly learn how things work, and any team member can take a story and complete it satisfactorily. The team’s global knowledge increases.
• The team can and should challenge subtasks added to a story to ensure that the envisioned solution is the best. Challenging and improving subtasks allows the whole team to participate and improves team knowledge, cohesion, commitment, and trust.
• Estimating the time for each subtask ensures that:
  • The actual workload will fit within the available workforce.
  • Misunderstandings are detected: if two developers come up with a different estimation, it’s probably because there is a difference in their understanding of what is to be accomplished and how it should be done. Resolving this misunderstanding early will prevent the story from having to be re-coded or corrected later.
  • Time tracking that shows the progress of the sprint will immediately reveal any problem in development. It’s nearly impossible to detect sprint issues by tracking the progress of the sprint using story points.

Tracking the progress of a sprint using subtasks’ time offers a major advantage over tracking using story points. Because stories are completed close to the end of the sprint and story points are removed only when the story is completed, any issue becomes visible when it is too late to handle the situation, as illustrated in the drawing below.

On the other hand, when we track the time spent in subtasks, we notice the time burndown diverge from the ideal burndown line as soon as a task takes longer than estimated. The team can proactively and constructively solve the problem. It helps the team’s morale because rather than endure failure at a point when nothing can be done, the team can act and decide how to minimize the impact on the sprint. It strengthens the team spirit, the sense of control, and the commitment to success.

An Opportunity to Grow Together

Even if a sprint ends in failure, ultimately, the outcome will be positive because the team has worked together to reach a goal and has learned from its errors. Failure should always be handled as an opportunity to improve and strengthen the team, and not as a source of bitterness and recrimination.

Conclusion

Sprint Planning is not a ceremony to decide what story to put in the sprint, but a ceremony to build the team, create commitment and accountability, and plan for success. A few hours spent on a Sprint Planning are always a worthwhile investment in the success of a project.