Do You Think You are Done?

Alex Kudinov — March 22, 2019

— March 22, 2019

Second freshness – that’s what is nonsense!

There is only one freshness – the first – and it is also the last.

And if sturgeon is of the second freshness,

that means it is simply rotten.

Mikhail Bulgakov, “Master and Margarita”

As a Professional Scrum Trainer for Scrum.org I get to think about the Definition of “Done” and its meaning a lot. In one of the Sprint Planning event the other week, a Product Owner asked an innocent question, “I need this small thing changed, how long that might take?” An answer followed almost immediately, “it’s just a couple of lines of code.” I heard that conversation many a time before and almost always it ended with, “of course we are going to get it done, no problem.”

To those kinds of exchanges, I always have a couple of questions. What exactly do you mean you will get it done? Do you know what getting done means? Quite often the responses are either an indignant, “of course we know what done means, we have been doing it for years, do you think us fools”. Sometimes I just get a blank stare, “what do you mean.”

For Scrum teams the reality is quite a bit more complicated than that though. Entering the Definition of “Done” – one of the most misunderstood and often neglected topics. However, it’s such a fundamental concept to making Scrum work that it deserves to be brought up repeatedly.

Some Scrum Fundamentals

A bit of a Scrum fundamentals refresher. Scrum is a framework to address complex adaptive problems. The empirical process control theory, or empiricism, is the foundation of Scrum. Empiricism, according to The Scrum Guide, “asserts that knowledge comes from experience and making decisions based on what is known.” Think about it for a moment as too often we glance over this statement and move on. Software development is done by knowledge workers[i], or “smart creatives” in Google parlance[ii]. Organizations hire them for their existing knowledge. It is what they use in their daily work, and what eventually becomes the outputs and outcomes of their efforts. Experimentation and experiences are fundamental for obtaining the knowledge we are seeking[iii]. Many times a day these knowledge workers make important decisions in the course of solving those complex adaptive problems. Consequently, the more knowledge they possess, the better decision they make.

Empiricism and Scrum are founded on three pillars. Those are transparency, inspection and adaptation. Each pillar deserves its own study. However, I will focus on transparency here.

The Definition of Done and Transparency

It is important for everyone to be on the same page when a team member says, “I am done with that piece.” What exactly does that mean? Is it coded? Is it tested? Has it passed all necessary checks? Does it work as intended? Does it comply with all the rules and regulations the organization must follow? Is it ready to be released? Imagine a Product Owner, or another team member, or any stakeholder must ask all these questions every time a piece of work is completed. It would be a fertile ground for things going wrong, mistakes made, misunderstandings occurring, and trust in team’s capabilities lost.

A good Definition of “Done” by its existence addresses all these potential problems and more. It provides transparency into the state of every product backlog item and the increment. If I were to pick a single question the Definition of “Done” should help answering it would be, “Is our increment in a releasable state?” Inspecting the sprint backlog and the increment by applying the team’s Definition of “Done” should provide a clear answer to that question.

My take on it

This is one thing in Scrum that is quite black and white in my mind, there is no “almost done” state. You are either “done” or “not done”, period; your sturgeon cannot be of second freshness. Now, that does not mean that the Scrum Team under no circumstances can release a product that is not conforming to its Definition of “Done”. But should it choose to do so, it should be absolutely transparent as to what is happening, why it is so, and maybe a conversation should ensue as to what needs to happen to correct the deficiencies. Another conversation should focus on the longer-term corrections needed to ensure that the team does not release another “undone” increment in the future.

There were quite a few debates over the Definition of “Done” not being a Scrum artifact. On the one hand the Definition of “Done” is an embodiment of Transparency. The Scrum Team usually inspects and adapts its Definition of “Done” during their retrospectives. On the other hand, its existence provides transparency to the state of items in the Sprint Backlog and the state of the increment. The question is still open and quite hotly debated.

Another way the Definition of “Done” represents transparency pillar of Scrum is by shedding a very bright and harsh light on team’s technical “non-excellent” practices. Are you struggling with getting to done because too much manual testing needs to be performed? Maybe it’s time to re-evaluate your test automation strategy. Build and deploy processes takes too much time that gets in the way of getting to “Done” early and often? Time to take a second look at your CI/CD pipelines, their performance and what they actually are designed to achieve.

The Definition of “Done” in the PSM II Class

The PSM II course includes a great exercise to improve students grasp of the Definition of “Done”. Firstly, we introduce the Aspects of Done. Those represent a series of steps involved in software development. The steps are development, testing, integration. Secondly, we introduce a series of Examples of Done cards.

The students will have to match them with an Aspect of Done where these examples are most likely to occur. This activity is very engaging and brings up a lot of conversations and arguments. Consequently, students learn a lot about different approaches to the Definition of “Done” from their classmates.

Then come the problems. The facilitator introduces a deck of cards that describe potential problems with the work and asks the students to position these cards into the Aspects columns where we are most likely to detect these problems. Another round of talks and more debates and arguments (sometimes quite heated) ensues.

The students leave the class with a clear understanding of why a Product Owner might care about the completeness of the Definition of “Done”, how it affects predictability and what it tells us about the transparency of the increment.

To experience this great exercise and more I invite you to attend one of the PSM II classes.

In conclusion, next time you hear “it’s only 2 lines of code that need to be changed” I suggest you to remember what your team’s Definition of “Done” calls for and think of the implications these “2 lines of code” will have on your work, your forecast, your Sprint Goal, and your commitment.