In the past 20 years, I’ve been involved in a wide variety of software- and product development efforts. At the beginning mostly as a project manager, and afterward as a Scrum Master. Sometimes I was right in the middle of a ‘waterfall’ project, other times I was 100% dedicated to a Scrum team. In recent years, my focus shifted more towards supporting teams from the sidelines.
One of the patterns I’ve noticed in all these years is how teams, management, and stakeholders respond to complexity. The more complex the product is, the more time everyone wants to think. First think, then build. The general mindset was to find your way through complexity by thinking.
“Let’s find our way through complexity by thinking…🤔”
This is something I already noticed before my Scrum experience started. We used to call this the ‘thinking phase’, and it resulted in a wide variety of plans: functional designs, technical designs, database designs, architectural blueprints, test cases & scenarios, roadmaps, release plannings, etcetera. Sometimes this would take a month, but 6 months and longer wasn’t an exception either. Once I started with Scrum, we often still created all of this, but turned it into a “Sprint 0”.
Over time I discovered that this approach doesn’t make sense at all. Many of the plans, designs, and blueprints we created upfront were already outdated before we started building. They disappeared in someone’s drawer never to see daylight again.
Yet I’ve always struggled convincing organizations to try a different approach. To not spend so much time thinking and creating all these plans packed with assumptions. This was until Christiaan Verwijs and I designed the “Definition of Done” exercise as part of the Scrum.org PSM II class. From that moment on, running the exercise showed team members, managers, and stakeholders why they should spend less time thinking and focus more on doing.
In this blog post, I’ll share a rough outline of the exercise, in which I’ll focus on one part in specific. This is a part that shows why a Sprint 0 doesn’t make sense at all!
An impression of where & how I filled my early days as a project manager…
The flow of the Definition of Done exercise
Let’s start with a rough overview of the Definition of Done exercise. I won’t describe it in full detail, the (digital) exercise already contains a step-by-step explanation.
- Step 1 — Clarify the purpose of a Scrum team. Ask the group to summarize the purpose of Scrum in a oneliner. Ideally, the result is something like ‘create a useful, valuable, done increment each Sprint’.
- Step 2 — Introduce the ‘Levels of Done’ cards. Invite the group to order the ‘Levels of Done’ cards. Emphasize that this is a rough representation of the workflow that most items in a Sprint Backlog go through during a Sprint, preferably one by one.
- Step 3 — Distribute the ‘Aspects of Done’ cards. These blue cards contain examples of ‘rules’ that teams can have on their Definition of Done and that represent work that happens in the Sprint.
Examples of ‘rules’ a team might have on their Definition of Done are:
“The code for the PBI has passed a code review by another developer”
“PBI has passed testing on a variety of devices (tablet, smartphone, laptop)”
“An end-to-end functional review has been done with a key user”
“PBI integrates correctly with work done by other teams working on the same product”
“PBI (Product Backlog item) has been successfully deployed to production”
The ‘Levels of Done’ cards (top picture) and the exercise in full swing (bottom picture).
- Step 4 — Distribute the ‘Problem’ cards. These red cards represent unexpected problems that may emerge that may be discovered somewhere as the work on an item is being done. For each problem, the group connects the ‘problem’ cards to the workflow phase where it’s most likely to be detected.
Examples of unexpected problems that might emerge are:
“Writing the code for the PBI takes significantly more time than expected.”
“The code written for the PBI fails to merge with work done by another team.”
“The interface of the PBI is badly broken on tablets.”
“Users are complaining about the PBI because it uses terminology that is very different from what they are familiar with.”
“The PBI is missing a key element that the Product Owner considers necessary before releasing it.”
- Step 5 — Discuss patterns and impact. With the patterns of ‘rules’ and ‘problems’ cards visible, you can now debrief together what this means about your work together. And more importantly, the risks and unpredictabilities that are inherent to that work.
- Step 6 — Clarify where Scrum starts. The Scrum framework only reduces the risk of complex work when teams can at least deliver a releasable, Done Increment every Sprint. Anything less isn’t Scrum and won’t help your Product Owner and stakeholders to reduce the risks of the investments they’re making with their time and money.
A pattern that emerges
By distributing the ‘aspects of done’ cards and the ‘problem’ cards a clear pattern emerges. Each step in the workflow of developing a Product Backlog item enables the Scrum team to detect potential problems. While writing the code, the developers might detect it takes way longer than expected. While running automated and/or manual tests you discover a nasty bug. When trying to integrate the work done by other teams — working on the same product — misalignment causes problems. Just before you want to release the Product Backlog item, the Product Owner discovers the essential elements that really must be included. And totally unexpected, the terminology used for a new feature causes confusion among the users.
All of these problems are things the Scrum team didn’t predict upfront. They only discovered the problems by doing the actual work. They might already have a gut feeling about the potential problems, but only by starting the work, they could validate their assumptions. As a team’s Definition of Done becomes more comprehensive, the chance of problems popping up decreases.
As a team’s Definition of Done becomes more comprehensive, the chance of problems popping up decreases.
So what happens before there’s any code?
As you can see in the picture below, the step ‘before there’s any code’ also contains some blue cards. This means that the Scrum team is doing work that’s needed before they can start writing code for the Product Backlog item. Examples of such work are:
“ Tasks for PBI have been identified.”
“PBI has been verified to conform to the architectural conventions of the organization.”
“PBI has been verified to conform to guidelines set by the organization for the use of images, labels, and texts.”
“Requirements have been identified for the PBI.”
“A solution has been designed for the PBI and is awaiting implementation.”
“Visual design for the PBI has been created.”
All of this work is totally fine and valuable. It needs to be done at some point in time. You could even plot all the work I used to do in ‘Sprint 0’ beneath the card ‘before there’s any code’: functional designs, technical designs, database designs, architectural blueprints, and test cases. But no matter how much time you spend on creating these plans, identifying requirements, and creating mock-ups and designs for potentially new valuable features, they remain assumptions and guesses.
“No matter how much time you spend on creating plans, they remain assumptions and guesses.”
You assume that all necessary requirements have been identified. You assume the solution the team has in mind will solve a problem. You assume the new feature is valuable for users. Etcetera. Only by starting the work on new Product Backlog items, do you validate these assumptions. Only by doing the work, do you discover if your ideas and assumptions actually made sense. Only by inspecting ‘done’ Product Backlog items and done product increments, you learn what is needed and prevent spending time and money on the wrong things.
“Only by doing the work, do you discover if your ideas and assumptions actually made sense.”
Instead of considering the time before there’s any code the ‘thinking phase’, or ‘Sprint 0’, I prefer the call it the ‘assumption phase’. The term ‘thinking’ still implies that there’s lots of value in doing it, while the ‘assumption phase’ better emphasizes the risk it contains. Contrary, I prefer to call the time when the team starts to develop a new feature the ‘validation phase’. It better emphasizes how doing the work validates important ideas, questions, and assumptions. In the end, that’s what empiricism is all about. That’s what Scrum is about: limit risk, increase predictability, improve quality, and deliver value to your stakeholders sooner.
“That’s what Scrum is about: limit risk, increase predictability, improve quality, and deliver value to your stakeholders sooner.”
The essence of Scrum explained in a comic. You can download a free high-resolution version here.
Closing
In this blog post, I explained how the Definition of Done exercise can show participants why Sprint 0 isn’t a smart idea. You can’t think your way out of complexity, you need to start doing. That also matches the essence of Scrum: limit risk, increase predictability, improve quality, and deliver value to your stakeholders sooner.
If you’re interested in learning more on this topic, check:
- The blog post “Take Your Definition of Done To The Next Level”
- Read our article “On Complexity: Why Your Software Project Needs Scrum”
- Listen to the podcast episode “Why Scrum Requires Completely Done Software Every Sprint”
Interested in learning more about Scrum and this exercise? Join our public Professional Scrum Master II course. Send us a message to explore in-company possibilities.