One of the things I like about freelancing is the clarifying moments it often provides. One of those has to do with the concept of “billable hours”. We generally understand that when you are being paid a salary you add value beyond the time you spend in front of a screen. That said I do find that when charging by the hour it tends to focus my effort to make sure every billed hour is delivering the value I was hired for. And what does that have to do with DONE criteria? Well, everything actually. Consider the following thought experiment. Suppose when you were sizing a story you did so knowing that you would get paid based on that size. Furthermore, suppose there was an acceptance step in which you had to demonstrate that you had implemented the story sufficiently well to get paid (set aside all the grievance procedures that would be required to work this way and just walk with me down this road a bit). If you’re thinking even a little ahead of me here you will already see where I’m going.
First – I’m not a certified Agile anything. It’s just been the air I’ve been breathing for almost two decades. I was not hip to the Agile Manifesto as early as some, but I used and advocated for iterative approaches to software development before I had even heard of Agile. I took to agile methods like someone dying of thirst who has realized that in software waterfalls, unlike the real thing, all of the water starts at the bottom and gravity is not your friend. As an industry, we’ve been doing this long enough that we can observe with a certain detachment that agile methods are frequently practiced just as ineffectually as waterfall ever was. It is not my intent to dwell on this (I’m not bitter… ahem). But there are some things I feel are worth standing upon squarely, jumping up, and, as the natural course of events would dictate, coming down, again and again. One such thing is my number two pick for the agile practice most observed in the breach: The dreaded “Definition of DONE” or DOD. Incidentally, my pick for first place would be “Whole Team”, but that is a topic for another day – reason being that it’s difficult for an individual developer to move the needle on Whole Team. But writing good DONE criteria is like picking up garbage. No one wants to do it, but everyone wants it done – making it a perfect vector for someone in the trenches wanting to strike a blow against the fortress of anemic agility. Nor is it my goal to reiterate the guidance, much of it quite good, you can find in 20 seconds with a search engine. My goal is to persuade you to care quite deeply about good DONE Criteria.
It has to be said I was more than a little fanatical about DODs long before I did any freelancing (the phrase “here we go again” might just possibly have been heard). But it has provided fresh insight into just why this is so. There’s a reason we use “story” to describe our work. Someone who uses your software to do a job will be able to do something valuable they could not do before. The DOD needs to tell a story that captures the essence of what good thing will be true that was not true before – the sine qua non. Ideally, it does so in a way that steers you away from blind alleys and steers you toward the win. This is not to say that details are sketchy – far from it. But the details should fence the outcome and allow correct inferences to be made about finer details that may not all be spelled out. There might be a new stored procedure that didn’t exist before – but does anyone care? There should be automated tests that didn’t exist before, and you should care – but that is not DONE Criteria (more on quality standards shortly). You use the DOD to build a shared understanding with the stakeholder of what will be true at the end of the story that will delight them.
The funny thing is, we do this quite well almost routinely:
Meet me in the lobby of Il Terrazzo (the one on 1st Ave) at 7:30pm tonight for some great Italian food. We will debrief about the client meeting we had this morning and come up with next steps. I will make the reservation and confirm with you.
And yet when we start out to build software, we take leave of our senses and somehow end up with this:
As a driver I will travel by car for 10 minutes so that Marvin can have dinner with me. 1. The car will be blue 2. The car will have four doors 3. I will change the oil and fill the tank with gas before leaving
All of these could be perfectly fulfilled while utterly failing to arrive at the same restaurant at the same time, for cuisine that you like, or even talk about the client meeting. Why, when we are frequently able to do this well, do we so frequently do it appallingly bad.
Let’s go back to the original thought experiment. If getting paid depended on understanding what the stakeholder thought DONE looked like would you be content with the second DOD? Would you want to know enough that you could take some initial steps with a degree of confidence? Would you want to have a reasonable understanding of the risk surface you were dealing with before sizing the story? In other words – would you try to write DONE Criteria like it mattered? Exactly.
Part of the problem is that having a dinner meeting is an example where we have a good understanding of the landscape already. The moving pieces are at our fingertips. This is usually not so much the case when building software. Yep – it turns out this is hard. You have to be willing to tease out an understanding of the landscape with the stakeholder. That takes time and energy that we frequently have not budgeted for in the planning process. Without a forcing function it’s easy to push past this as “stuff we’ll sort out later”. A forcing function (getting paid) makes it unacceptably risky to “sort it out later”.
But wait, isn’t Agile all about going back and forth with the stakeholder and working out those details as they emerge so we have better information to work with? Absolutely. But in practice there is a limit to how tight you make that feedback loop. Somewhere between having the stakeholder (or stakeholder proxy) sitting next to you while you write code and having a 30-minute meeting with the stakeholder once a month (neither of which is desirable) is the reality we will live in. How many blind alleys do you want to go down, and how far, before you have a chance to check your assumptions?
So where is the balance point? There is a concept of deferring resolution to the last responsible moment. You keep harvesting information until it would be irresponsible to further delay making a decision about how to proceed. But there is always a considerable amount of information that will yield readily in a reasonable amount of quality time with the stakeholder. It is irresponsible to delay harvesting that information when it is there for the asking up front. It can be used to generate better DODs and inform the path forward. Make it clear to the stakeholder that you cannot responsibly proceed until they have invested that quality time. When you have their ear, don’t waste their time – make it count. The improved DODs will pay for themselves. To summarize, front-load the discovery effort to the extent that the landscape can be readily exposed in reasonable blocks of time with the stakeholder. Will there be risks that need to be investigated in more depth before resolving some decisions? Certainly. That’s why we iterate.
If you are a programmer, perhaps you are wondering – isn’t writing DODs someone else’s job? Perhaps. But go back to the thought experiment – do you really want to be a passive receptacle? This does no one any good. Take an active role in shaping the story to improve your chances of delivering something that delights.
About those quality standards – they matter, a lot. But following good practice is table stakes – not DONE Criteria. That needs to be the water you are swimming in. Sure, if your team is struggling with the quality standards it is sometimes helpful to include them in the story… just to make it explicit. But I would suggest that if this is where you find yourself, a better approach would be a mechanism external to the stories themselves (checklists, team working agreements, check-in reviews, etc.). Some things aren’t optional – so don’t burden the DODs with them. And to be brutally honest, the stakeholder may not understand them well enough for them to be part of a meaningful shared understanding. They almost certainly care that the output of the story be operationalized and unapologetically ready for production. They probably expect cars to have wheels. It’s very context dependent, but engineering due diligence requires you to take responsibility for baking some things into the cake. But that’s another story (How To Risk-Manage Your Way Through Almost Anything).
As I indicated at the beginning – no doubt you can find plenty of good guidance out there to help you write DONE Criteria. But your north star is this: Write them like it matters.