The third part of the Agenda is here.
Last time, we talked about reviewing User Stories from the Product Backlog and clarifying them where needed, committing to completing the selected User Stories in the Sprint through acceptance by initial Developers, breaking down User Stories into Tasks by the respective initial Developers and deciding how to build the selected User Stories into a “Done” Product Increment during the Sprint.
The last two components of the Planning Agenda are:
- Set up the Sprint Goal (a simple sentence used by the Product Owner to inform Stakeholders of the goal of the upcoming Sprint).
- Refine User Stories in the Product Backlog if needed.
So, let’s take a closer look at these points.
Set up the Sprint Goal.
We do use the Sprint Goal in ScrumOne as a method of communication with Stakeholders and the Team itself. The Sprint Goal is created through mutual cooperation between the Product Owner and Developers.
It has to be short and understandable. The Stakeholders should be able to know right away what you are working on during the current Sprint. It has to be written in language that they understand. Most likely, the Stakeholders will not have time to figure out what some non-specific description means. They have to understand what you want to achieve in the current Sprint.
The Sprint Goal also tells the Stakeholder what they are paying for within the current Sprint and what the finished product increment will be after the Sprint.
As I wrote above, the Sprint Goal is also for the Team itself. Various distractions can occur during the Sprint, but the focus always has to be on the Sprint Goal. It does not matter if all the User Stories that were planned for the current Sprint are not finished, as long as the Sprint Goal is achieved.
Refine User Stories in the Product Backlog if needed.
Within ScrumOne, we are trying to get to the point where we have the Backlog refined for at least the next two Sprints. This is because we want our strategy to be visible, for our Stakeholders to know what to expect and to try to avoid needing to refine User Stories during the Planning. We are trying to make the Planning as smooth and short as possible. But of course, in the real world, nothing always goes smoothly and without unexpected issues, so it’s possible that during or after the Review, the Team receives feedback that needs to be included right away within the next Sprint. This means it can influence already refined User Stories or it can demand the creation of a new User Story that has to be refined during the Planning. If this happens, we do refine only the User Stories that we are going to take into the current Sprint. Any other refinement is left for the Refinement session.
My last reason for having the Backlog refined for at least two Sprints is because the Team can take into the Sprint all the refined User Stories from the Product Backlog. Because the Developers are the ones to decide their own capacity for the Sprint, they could bring a lot of work in, but run into a situation in which we come to a User Story that is not refined yet.
And with that, we have completed all the pieces of a Planning Agenda. So, thank you for reading and looking forward to another article about Perfect Planning.
Have courage and be kind.