Just wanted to share with you a few thoughts on the definition of done, and why I believe it to be one of the most important anchors of an agile team to keep alive and iterate on often.
The highest priority of any team who strives to be agile is to satisfy the customer through early and continuous delivery of valuable software. Working software is the primary measure of success. You can substitute “software” with “product” or “solution” if that makes sense. With that single priority and single measure in mind, I typically work backwards with teams to help coach them when defining done.
In my experience, when teams are first introduced to the definition of done concept, they tend to categorize done by functional work areas such as “developer done” or “test done”. This is not ideal because this approach often reinforces silos within a team, and risks violating our highest priority that is to ship valuable software. Earlier in my career I was in a situation where a group of C-Levels chewed me apart for having the nerve to say “well, it’s developer done but needs to be tested before we can ship”. The CTO responded with something along the lines of “then don’t fool yourself – it’s not done, there’s no value delivered. Fix it.”. Of course, at the time I was upset and embarrassed. I wanted to respond with “but we completed all of our points!” but I knew better because the CTO’s face was fiery red and there was no sense in poking the bear just to nurse my pride and ego. It was then I realized that outputs don’t mean a thing if the outcome is not there.
The difference between outputs and outcomes is profound and fundamental. Outputs are defined as the things we build. While outcomes are the difference that our things make. For example, we might build a new medical device (output) but that device makes the patient safer during surgery (outcome). Outcomes are the difference made by the outputs. Outputs, such as story points and velocity, enable teams to deliver outcomes. But without meaningful outcomes, outputs are unnecessary and insignificant.
For emphasis, an agile team’s ultimate outcome is to satisfy the customer through valuable software. It is not to make our story point burndown chart look good. It’s dangerous to tweak our definition of done to make it so that our story point velocity looks good. When defining the definition of done, I encourage scrum masters and teams to challenge the team to focus on the customer value. For example, delivering stories at the end of a sprint and releasing to an environment where customers can use the software provides value. Teams that are really mature in their Agile and DevOps practices consider done if code is shipped to production.
I am guilty of creating separate stories just for testing, instead of having testing be part of the definition of done. It blew up in my face when we went to go-live with a major release, only to realize we were approaching our work in anything but test-driven. Testing was assumed to be someone else’s job, as opposed to it being a responsibility of the entire team. It was a time in my career where I knew I failed the team. I was focusing too much on wanting them to feel good by having the illusion of all the stuff that was getting to done, but in reality I wasn’t coaching the team to focus on the outcome that ultimately mattered.
While I still measure things like story points, I certainly do not give them the importance I once did.
