Research shows that quality is an important driver for continuous improvement in and around Scrum teams. And that makes sense. When the bar for quality is low, or people don’t even know what the bar is, there is no way to tell how well you’re doing. The Scrum framework introduces the Definition of Done to help teams develop a shared understanding of quality. This is important for the team and its stakeholders. We often see that teams do have a Definition of Done, but it is in someone’s drawer and not actively refined, referred to, or improved.
So, how strong is your team convinced that the quality of work matters? Do people often talk about quality? Is there a clear and shared understanding of what it means? There’s no point in shipping fast when the quality of the work is low, as it will only result in bugs and unhappy users.
We created 3 do-it-yourself workshops to support your Scrum team in answering these questions. All of the workshops include a step-by-step approach to use them and help you move in the right direction.
The workshops are:
- Help Your Team Get Started With A Definition of Done
- Improve How Your Team Uses The Definition Of Done
- Take Your Definition Of Done To The Next Level
In this blog post, we offer you a short description of these workshops. We hope it inspires you to give them a try. Once you’ve used them, let us know the results, let’s learn and grow, together!
The Purpose Of Scrum
If you were to capture the purpose of the Scrum framework in a single sentence, it would be to work empirically by delivering a Done Increment at least once every Sprint. This is also why it is so important that Scrum teams spend time clarifying what is involved in creating an increment that is Done. What work is required to do this? Which checks and tests are necessary to conform to our internal quality guidelines? Who needs to be involved in this? This shared understanding is called the Definition of Done, and it usually takes the form of a checklist.
The Risk Of Assumptions
The work on the Product Backlog tends to be chock full of assumptions until they are completed and put into the hands of users. For example, “Will implementing this item improve the experience of users?”, “Will users understand how it works?”, “Does it perform well enough?” Other assumptions will be about the work that needs to be done to implement the item, like “How easy will it be to test and deploy this item?”, “What issues will we run into when working on this item?”, “How well do we understand what to build?”.
Every assumption represents a risk. The risk that you misunderstood what a user asked for and need to rework it. The risk that you run into technical limitations when you start writing the code. The risk is that the feature performs much worse than expected. The risk that writing automated tests turns out to be much harder. Or the risk of spending money and time on a feature that ends up not being used. What these risks all share is that they result in more and unexpected work somewhere down the line. And this kind of “carry-over” work has a tendency to be invisible until it pops up when you least expect it, messing up what you are working on in that Sprint. This is called “Un-done work”.
How To Manage Risk?
The best way to prevent the risk of un-done work is to make sure that each Sprint results — at least once — in a Done Increment that can be potentially released. That means that the Increment has been fully tested and is working. Texts and visuals are in their final state. Documentation and deployment packages are up-to-date. And performance and security conform to organizational standards. From here, the increment can be released to users with the proverbial press of a button. From this point onward, you know that there will be little to no potential un-done work that can mess up the focus and predictability of future Sprints. More importantly, it allows you to exercise empirical process control by releasing the increment to see if this moves your product closer to its ambitions, rather than assuming that it will.
Creating a Done Increment for every Sprint is certainly challenging. But purposefully so. Because putting this amount of pressure on the system that is creating the product — to do all the work necessary to achieve this — shows clearly where improvements are necessary. Where skills, tools, and technologies are missing. Where bureaucracy is getting in the way. Where impediments need to be removed in order to actually work empirically and reduce the risk of complex work. By keeping a laser focus on delivering a Done Increment at least once every Sprint, the system will start hurting in the right spots and create opportunities for inspection and adaptation.
As the ability of Scrum teams to deliver Done Increments moves to the right, the risk of un-done work decreases. And predictability increases.
In A Nutshell
So, if you need to explain this to your team, here are the key takeaways you should emphasize:
- The Scrum framework requires a useful, Done Increment at least once every Sprint. Only then can a Scrum team truly validate underlying assumptions with their stakeholders. Each Increment represents a step towards achieving the larger Product Goal;
- The Definition of Done makes explicit what the state of the Increment should be when it meets the quality measures required for the product. The Definition of Done applies to the Increment as a whole and to each Product Backlog item that is a part of that Increment. Work that does not meet the Definition of Done is not considered part of the Increment;
- As the Definition of Done becomes more comprehensive, the chance of problems popping up that require further time from the Scrum team decreases. This improves quality, predictability and lowers risks;
- Scrum teams that are unable to deliver Done Increments every Sprint are unable to truly reduce the risks that are inherent to complex work. Although they may already benefit from the rules of Scrum, they are not doing Scrum yet.
- When teams and organizations focus their efforts on delivering useful Done Increments every Sprint, they will rapidly discover what impedes their Agility. This can range from missing skills, obsolete technologies, dependencies to other organizational impediments;
The 3 Do-It-Yourself Workshops
Note that we ask for a small donation in return for each workshop (5 USD). You can also support us on Patreon to download our digital content for free (note that this benefit starts from the “Contributor”-tier and onward).
Help Your Team Get Started With A Definition of Done
The Definition of Done defines what a high-quality Increment looks like for your team. It usually contains such criteria as “The code is covered by unit tests” or “Support documentation is available”, or even “The language has been proofread by an editor”. The more clear your team is about what quality means to them, the less rework and the more professional your results will be.
We created this do-it-yourself workshop to familiarize your team with the concept of a Definition of Done and to create the first version of their own. So, if you start with a new Scrum team, or your existing team decided to start using Scrum, run this workshop to create your Definition of Done. It’s a vital step to kickstart your team in the best way possible!
This do-it-yourself workshop uses the Liberating Structure “Min Specs” to create a Definition of Done.
Improve How Your Team Uses The Definition Of Done
For this do-it-yourself workshop, we assume you already have a Definition of Done. The biggest challenge for your team is to actually use it. Over time, the Definition of Done has become this piece of paper next to the Sprint Backlog that nobody really pays attention to. Product Backlog items are moved to “Done” without checking the Definition of Done. Maybe some items live up to the quality standards, but chances are they don’t.
Many Scrum teams don’t purposefully ignore the Definition of Done, they often don’t know how to apply the rules. Sure, the rule of “all code must be reviewed by another developer” sounds great, but our Sprints are packed with so much work that it feels impossible to do. The purpose of this workshop is to revive your Definition of Done and to actually put its rules into practice!
This do-it-yourself workshop uses the Liberating Structure “Purpose-to-Practice”. You can download a high-resolution version of this poster here.
Take Your Definition Of Done To The Next Level
For this do-it-yourself workshop, we assume you already have a Definition of Done and your team applies the rules for each Product Backlog item. However, you do feel that there’s an opportunity to raise the bar. Your team is ready to challenge themselves and to explore how to expand the Definition of Done and validate assumptions quicker, and deliver value to stakeholders sooner. All of this is without comprising quality. The team wants to see if they can build products with an even higher quality standard!
The purpose of this workshop is to diagnose the current rules of the Definition of Done and to identify where you can make improvements. The primary Liberating Structure we use is Ecocycle Planning. You can run this workshop with your team, invite other Scrum teams working on the same product, or even include your stakeholders!
This do-it-yourself workshop makes use of the Liberating Structure “Ecocycle Planning”. The pictures show how we used this structure at one of our clients.
Closing
We created these do-it-yourself workshops to help your Scrum team create, use, and improve their Definition of Done. This is crucial because the Definition of Done reflects the quality the team delivers, and quality is an important driver for continuous improvement in and around Scrum teams. If you tried the workshops, let us know how it went. Your thoughts, ideas, and experiences are invaluable to us. Only together, we can create even more valuable content, and unleash the superpowers of Scrum teams, all around the world!