The majority of you reading this post have probably worked with Scrum already. Moreover, you might even be a Scrum Master. This is very good since you need to have some experience with Scrum to read this article. I will not describe the Scrum framework in detail (check out this Scrum Framework Poster for the overview), nor motivate why Scrum is a good framework for complex product delivery. You might already know all the Scrum Events, Artifacts, Roles, Rules and also which Scrum Pillars and Scrum Values there are. When you know all this, are you doing Scrum then?
On the surface it might look like Scrum, however, in reality, it might be Zombie Scrum, ScrumBut, or both. In Zombie Scrum, you go through all the notions of Scrum but there is no beating heart in the team. There is no energy, no desire for continuous improvement, no desire to uphold the three Scrum Pillars or the five Scrum Values (see Dave West’s description of the five Scrum Values and article by Hiren Doshi about the Scrum Pillars). In ScrumBut, there are exceptions to the Scrum framework, for example, not all Scrum Events and Scrum Artifacts are in place.
Why is this important? Is it not enough to do Zombie Scrum or ScrumBut? I will publish a series of posts where I look at each Scrum Event and Scrum Artifact in regards to the three Scrum pillars and the five Scrum Values. This is the first post – Sprint planning.
Sprint Planning and the Three Scrum Pillars
Sprint planning is a time-boxed event where a team discusses the questions of what can be delivered and how the work will be achieved in the next Sprint. Why is sprint planning an important event in Scrum? Let’s start with taking a look at the three Scrum Pillars, transparency, inspection, and adaptation.
If there is no sprint planning, how will that affect transparency? First of all, there will be no sprint backlog, which is one of the outputs from sprint planning. Without sprint backlog, there will be no transparency in regards to what the development team will work on. The alternative, in this case, is to let the team members work on what they think will give the best value. In the worst case, they will do it without any discussion or knowledge if this is the most valuable task or if someone else is already working on it. There is also no plan on how to achieve this functionality.
Another output of the sprint planning is the sprint goal. This is a goal that shall be fulfilled during the sprint by the development team. Without a sprint goal, transparency is decreased regarding the expected output of the sprint.
Without sprint planning, there is a lost opportunity for a formal event to inspect the items in the product backlog: the latest produced increment, the projected capacity of the development team, and past performance of the development team, which are all inputs to the sprint planning. Without the inspection, it is more difficult to make a forecast for the next sprint. Sprint planning is a good opportunity for the development team to ask for clarifications from the Product Owner regarding product backlog items.
The discussions that arise during the sprint planning help the team to make adaptations. These can be for example trade-offs between the development team and the Product Owner on what can be done during the next sprint. The things that shall be done are the things that give the most value. This adaptation will be difficult without transparency and inspection.
Sprint Planning and the Five Scrum Values
The sprint planning event can also help to uphold the five Scrum Values. At the same time that the scrum team upholds the Scrum Values, it will result in the best possible output from the Scrum Event.
Photo credit: Scrum Values Poster by Scrum.org
So, the five Scrum Values are:
What happens if the Scrum team does not show respect towards each other? Some possible consequences are that you arrive late to the meeting or come unprepared (relevant mostly to the Product Owner in this case). Furthermore, if the Product Owner does not show respect to the development team it might result in the Product Owner deciding what the development team will create in the next sprint, not considering the input from the development team, for example, when it comes to their capacity. Without mutual respect, it will be difficult to unify the development team to have a common sprint goal and, in this way, make it impossible for the team to reach a consensus on what should be achieved during the next sprint.
The development team needs to be open to each other to be able to make the best forecast possible. All the available input that the team members can contribute with needs to be put on the table. This will help to identify work tasks and make the most accurate estimations possible out of them. This results in better chances to not plan too much or too little work in the next sprint. The Product Owner needs to be open about the vision for the increment and should be able to answer all the questions about the product backlog items after his/her best ability. In their turn, the development team needs to be open about what can be done in the next sprint and about team’s capacity. The sprint planning also encourages everyone to be open in changing direction, since the sprints can only be maximum one-month long.
To get the most out of the sprint planning, the focus should be placed on the top items in the product backlog. Otherwise, time and effort might be wasted on items that either will be changed or even removed after more knowledge is obtained. In order to not exceed the sprint planning time-box of maximum eight hours, the focus is required to make sure that there are no irrelevant and lengthy discussions about estimations and details, since achieving 100% accuracy is impossible anyway.
Lack of courage leads to team members not speaking their mind, not participating in estimations, and not identifying work tasks. This leads to poorer estimations and also that required tasks might not be identified. Bad estimations lead to either overestimating or underestimating the amount of work that can be done in a sprint. Without courage, there is no questioning of the value of the product backlog items that are planned for the next sprint which can lead to a poorer understanding of why they are to be done.
Without commitment, team members can choose not to attend the sprint planning. If this is the case, the valuable input from these persons will be missed for estimations and work tasks identification. The Scrum team also needs the commitment to collaborate in order to get a better common understanding of the work that needs to be done for the sprint and to unify around a common sprint goal. There is a need for commitment to the Definition of Done in order to make better estimations and to be able to reach a common understanding for when something is considered “Done”, otherwise there is a risk for some tasks to remain undone which makes the software potentially non-releasable.
The sprint planning Scrum event is so much more than just a “plan for the next sprint”. There is certain depth here in regards to the Scrum Pillars and the Scrum Values, and it is needed in order to understand the purpose of the sprint planning and get the most of it (which is vital, otherwise the team will stop doing it since its value and purpose is not understood).
In this blog post, I’ve shared my view on why it is important to consider the three Scrum Pillars and the five Scrum Values to motivate and get the most out of the Scrum event sprint planning. By only going through the notion of sprint planning, or by removing the sprint planning, there is a loss of transparency, inspection, and adaptation. The five Scrum Values are there to help to get the most out of the Scrum Event, while at the same time the Scrum Event is there to help uphold the Scrum Values.
I am very interested to hear your thoughts. Are the Scrum pillars and values important to consider when doing sprint planning? Is sprint planning an important Scrum event? In the next blog post, I will write about another Scrum Event – Daily Scrum.
About Jan Nilsson
Jan is Senior Software Developer at Sigma Technology. He worked previously primarily as a software developer and programmed in C, C++, and Erlang. Since 2011 Jan has been working using Scrum and he has been Scrum Master since 2013.
Would you like to stay tuned for more insights from us? Follow us on LinkedIn to see the latest updates.