In this section we are going to see some real-life scenarios faced often by the Scrum Team(s) during Sprint Planning
Sprint Planning lays out the work for the Sprint. This is an event where the entire Scrum Team comes together. They craft an answer to the question “why are we doing this Sprint? What Value we will generate this Sprint?” – This becomes the Sprint Goal. The Scrum Team then chooses items from Product Backlog that will help them to achieve this Sprint Goals. These are the selected Product Backlog Items. Then the Scrum Team makes a workable plan. This plan helps the team members to get started. The Sprint Backlog keeps on evolving throughout the Sprint.
To read more about Sprint planning, read this article
Scenario I –
Developers and Product Owner are able to discuss and finish Sprint Planning quite early – is this OK?
Snehamayee’s Perspective
An important point to remember would be “Sprint Planning” event has a “maximum timebox”. Scrum Framework allows the Scrum Team to use “less than” maximum allowed timebox.
Like everything we do in Scrum, we need to keep in mind the objective of Sprint Planning. We can indeed finish the event if the objective is achieved. Detailed task lists and exact plan of who does what when estimates are not the goal of sprint planning. It is enough if the Scrum Team is able to define the Sprint Goal, has selected the right set of product backlog items to meet the said Sprint Goal and have a rough idea of how to work on them. The team does not need to know every task they’ll perform to accomplish this goal.
Scenario II –
Sprint Planning that lasts more than a day and turns out to be a stressful event for the Scrum Team
Snehamayee’s Perspective
Even though the Sprint Planning has a maximum timebox of 8 hours, it is a common experience for many Scrum Teams where they find the even the maximum allowed timebox does not seem to be enough. In my observation there are a few key factors contributing to this
- Not enough attention given to Product Backlog Refinement. Often the Scrum Team does not dedicate enough time and effort for the activity of Product Backlog Refinement. This will mean that when the Sprint Planning comes up, the Product Backlog Items are “ready” . In turn, these “not ready” items can lead to inefficient planning. Some times the Scrum Team may even select a Sprint Goal that is not attainable.
- Product Owner who is Pushy Sometimes the Product Owner tends to get carried away in the enthusiasm of delivering maximum possible value and pushes the Developers to accept more work within the Sprint. This will impact the Scrum Teams “self management” and may impact the quality of the work sometimes even causing the Scrum Team to miss the Sprint Goal
Scenario III –
Product Owner says he or She is not available for the Sprint Planning
Snehamayee’s Perspective
Often especially in a distributed environment Developers are at one location and Product Owner is at another location. In such a case, there is some disconnect between the developers and the Product Owner and Often Sprint Planning is considered a “time for Developers to plan their work”
How ever a very important aspect of Sprint Planning is the discussions Product Owners and Developers have. These discussions ensure that Developers understand what value they are producing and allow the Product Owner to be able to better predict the outcome of the Sprint
Like everything in life, if its an emergency or an one off occurrence, I would advise the Scrum Team to go ahead with Sprint Planning if there is no way to adjust and have the Product Owner present. I would caution the Developers and Product Owner both to expect some issues during Sprint,
However if this is becoming a pattern where the Product Owner is not available for the Sprint Planning, I would work with the Product Owner to coach the him or her about Product Owner’s role in Sprint Planning.
Scenario IV –
As a practice, a Scrum Team invites a lot of stakeholders to each Sprint Planning .These stakeholders then push the developers during the Sprint Planning to accept more work. Some times the stakeholders also argue about “which requirements are selected”
Snehamayee’s Perspective
Scrum Guide says “The Scrum Team may also invite other people to attend Sprint Planning to provide advice” – In reality, many teams make it a practice to invite a lot of stakeholders. This often leads to a lot of unproductive discussions and arguments about “whose requirements are being addressed / how much work is being done” … This hampers the Developers from making an actionable plan. In such cases, I usually coach the Product Owner to have detailed discussions with stake holders prior to Sprint Planning and invite non Scrum Team members for Sprint Planning ONLY if the team members feel they will need some extra clarification or information