So many eye-openers!
Nothing beats helping a new team kick off with probing questions to make the team think.
Last week I was asked to step in as the Scrum Master for a newly formed team that was going to have their first Sprint Planning. The team was formed with new joiners although they had plenty of experience in IT, working with Scrum and/or working in an Agile environment. This included the Development Team, but also the Product Owner.
I’d normally not start with a Sprint Planning and instead choose to have a kick-off, but it was a short notice request.
The Sprint Planning turned out to be very interesting as it made the team aware that there are several interpretations of Scrum.
Definition of Done
When we started the Product Owner was happy that two items were already refined. Then I asked the team: “Do you have a common understanding on when the items are ready, what work is required to get them to Done?”. I was happy when one developer immediately said: “Right! We don’t have a Definition of Done”. As a result we determined the first version of the Definition of Done for this team. This lead to a number of actions for the team because they had a lot of investigation to do to fine-tune the Definition of Done. For example: “what are the standard practices within the company?” and “are there any compliance rules”. These actions were put on the Sprint Backlog. This fits with Scrum’s guideline to add at least one team improvement goal to the Sprint Backlog.
Refinement
As soon as we had defined our Definition of Done I asked: “Do you all have a similar understanding of when and item is ready to be planned in a Sprint, when it is fully refined?” This brought forward the need for a Definition of Ready as it is commonly known. To avoid a lengthy discussion at this point and to be practical I suggested to start with INVEST. The Definition of Ready is not part of Scrum, the Scrum Guide only mentions ‘Ready’, but it certainly is a practice that is very useful for many Scrum Teams.
We then revisited the already refined items. We needed to discuss them again, because only now we were on the same page for this exercise. We decided to refine two other items, because then we would have a nice set of items for the first Sprint.
Sprint Goal
I then brought forward that the Product Owner should suggest an objective for the Sprint, resulting in the Sprint Goal. The team didn’t know what I was talking about. They never heard about this Sprint Goal. I told them that the Scrum Guide mentions the Sprint Goal 27 times! That brought them to defining a Sprint Goal which explained why we build the increment.
Commitment
When discussing what we needed to picked up in order to meet the Sprint Goal one of the participants raised the concern that they should not put too many items on the Sprint Backlog. He feared that they then had to jump through hoops to have them finished. And since they will start their first Sprint, how can they know what they can pick up? He thought that the Sprint Backlog would be seen as contract signed with blood. I replied that the Sprint Backlog is not a commitment, but a forecast of the functionality required to meet the Sprint Goal and the work needed to deliver the functionality into a “Done” increment. I didn’t even mention that commitment doesn’t mean “signed with blood”.
I advised them to be conservative in their planning. The Development Team is free to add items to the Sprint Backlog later if they notice that they have more time available: the Scrum Guide says that scope can be clarified and re-negotiated if required.
Scrum is founded on empiricism which means that knowledge comes from experience and you make decisions on what is known.
The Scrum Team then went on to discuss how they would approach the first Sprint. Although I was able to coach them here as well they did a great job in making a plan for the next few days mostly by themselves.
Main takeaways
The new team has professionals that have been working with Scrum for years. Apparently they all worked with their own flavor of Scrum. And they also had their misconceptions of what Scrum really is and what it isn’t.
But all in all it was an awesome experience. It’s really energizing to be able to coach these people and show them the potential of Scrum. And this was just the start!
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
My twitter profile is https://twitter.com/WJAgeling