Show me the Receipts: the Importance of Testing and the Definition of Done.
This is the fifth of a series of introductory posts about Scrum. The previous post discussed User Stories, and the Product Backlog.
Let’s start where the previous post left off: when is the Sprint Planning meeting over? During the meeting, the team discusses which USs will enter the SB, and which DTMs will be responsible for each US – but there’s one more thing that needs to be discussed: the Definition of Done (DoD), a list which represents those specific qualities that a US must have in order to be considered complete.
The engineers in the crowd may remark how similar the DoD is to “acceptance criteria” or a “requirements list”. In fact, they’re exactly equivalent, with the only difference being that a DoD is grouped under a US. Engaging the DTMs in the process of listing the items in the DoD means they’ll understand the scope of the USs in the PB and SB – and those items in the DoD will be a boon to them when it comes time to organizing their independent work! Finally, the DoD is testable, which means it is possible to check to see if every item in the DoD has been accounted for.
Life Without a DoD
Okay, so you’re a SM. You’ve worked with your PO to prioritize an effective PB filled with a set of descriptive USs (all of which flow from your team’s EUS) and you’ve held a marathon Sprint Planning meeting and your DTMs have all volunteered for the USs which suit them best. They’ve diligently worked the entire Sprint and, with the help of regular stand-up Scrum meetings to keep everyone on the same page, they completed the DoD for every single US in the SB for that Sprint. Shall we chalk this up as another successful day in the life of a Scrum Master and pour ourselves a cup of tea?
Well, maybe not quite yet. Let’s start by asking a very simple, but very profound question:
“How do you know?”
Let’s look at some examples:
- You built a thing…
But how do you know it does the thing you built it to do?
- You built a thing and it does the thing you built it to do…
But how do you know that what you built it to do is what you need it to do?
- You built a thing, and it does the thing you need it to do…
But how do you know what you need it to do is what your audience needs it to do?
Pouring that cup of tea would appear to be premature, indeed. There’s still work to do, here.
So, how do we know? In order to know, we have to do some science.
For too many people, the word “science” probably conjures images of laboratory denizens standing around bubbling Ehrlenmeyer flasks in white coats, nitrile gloves, and safety goggles – but don’t confuse the externals for the fundamentals.
Science is a way of thinking. The scientific method is the only self-correcting method for rigorously testing our ideas in order to see which ones reflect the true state of nature, and which ones merely reflect our own preconceptions, delusions, and biases about how we think the world works.
So how do we do it? Let’s start with the hypothesis, a testable statement in an IF/THEN format. Here’s a simple example:
IF I write a series of introductory blog posts about Scrum,
THEN a reader will be equipped to engage in self-directed learning about Scrum,
AND a reader will be able to start applying some Scrum principles in their teams,
AND a reader will learn that District 3 can provide Scrum training.
The DoD in this case, would be a blog post about each of the following: the History of Scrum, the members of the Scrum team, User Stories and the Product Backlog, Scrums and Sprints, and Testing. This is where the testability – or, ‘falsifiability’, of these hypotheses becomes important: If by the end of this series you don’t feel like you know enough about Scrum to study the material on your own, and you have no idea how to start applying Scrum in a team, and if you don’t know anything about District 3’s ability to provide some level of Scrum training, then this series has failed on its own terms!
Part of the beauty of the DoD is this: not only does it give the DTMs on the team a concrete list of work to tackle as they move towards a completed US, but because each item in the DoD is testable, a well-defined DoD allows the team to reduce inefficiency and move confidently towards a better and better product.
As a Scrum Master, the most important thing by far will always be your ability to ask the right questions. I say “the right questions” because the easy thing to measure is rarely a good substitute for the right thing to measure! Not all tests are created equally, so let’s add one more question to our rack of “how do you know” questions:
How do you know your test is the right one?
The answer to this question is not always forthcoming, but if you stick to asking the golden question of “how do you know?”, then I think it’s very likely that you can find the right tests to keep your teams, processes, and products operating at a high level of efficiency and effectiveness.
If every item in the DoD can be checked off for every US in the Sprint, then you have successfully completed a product increment, and can (if you so wish) release the product – and then you pour yourself that cup of tea.
This concludes the introductory blog post series about how to start applying Scrum principles in you teams. I hope you found the series informative – or, at the very least, entertaining! Do you feel like you have enough information to effectively study Scrum independently? Are you confident to start applying some Scrum principles in you teams? If so, then this series of posts has been a success! If you have any requests for future posts, please list them in the comments below – and stay tuned to find out more opportunities to learn about Scrum at District 3!