Preetam De: Defining Done – The Holy Cow Approach

Reblogged with permission from Preetam De, the original author of
 this content, as a contributor to blogagility.com. Originally published 
on The Dark Horse on September 2, 2016.

 

While reading Invest on an Epic Story and get the job Done, there was a discussion about how the done checklist can be formulated with mandatory and optional sub-tasks. This article can be considered as the prequel which forms the basis of that implementation. A question we always come across while explaining how to define Done for a Story is –

 

What is “Done” or “Done Done”? How much is enough?

Truth is, it can be done or done done or done done done or (done)n. Done can mean a hundred different things for a story completion within a product backlog or within a team or for the consumers. The definition lies on the “baseline done” which everyone agreed to, before the work commence and the team takes it seriously as a discipline. The goal of this article is to get back to basics about defining Done for your story, I call it the “Holy Cow Approach”. This drives the thought process around “Done” and how you can resonate with a real life example.

Steaks.. we all love steaks (apologies to vegetarians). But we like it done according to our need. We do get annoyed if it’s not the right cut, colour, texture, seasoning or even the way it is presented.

 

Now, assume I am the diner and have made it very clear while ordering that I wanted it “Medium Rare”. That does it for me, that’s the minimal requirement (MVP). When the steak finally arrived, it turned out to be Medium.

How dare they?!

Dissatisfied with the outcome even though giving the correct requirement (I hope), as a furious consumer I have sent it back. My fellow diners sitting next to me ordered a rare (what an animal) and a well done (c’mon, it ain’t a burger). They did get their steak as they like, on time and were fully satisfied with the service and left a great feedback for the chef. That’s ⅔ aka 66.67% happiness rating.

So what went wrong? There were many possibilities of things that could have gone wrong, to name a few –

1. I might have said Medium and never said Medium Rare.. oops my bad. (Consumer)
2. Waiting staff might have missed it and wrote the wrong order (PO)
3. Head Chef might have vaguely communicated it (Dev team member)
4. Sous Chef kept it a little longer on the grill (Dev team member)
5. No one bothered checking if it was actually medium rare before serving (Inspection)

 

If we leave the point-1 aside (as wrong requirement), the rest depends on the team who delivered and is responsible, even if any one member missed a step before serving. May be the team should have considered it a part of the quality. Basically, what I have considered as Done as a consumer, wasn’t the definition the team knew or misinterpreted or was a human error. To them, say point-5 was the issue, 5 wasn’t really part of their Definition of Done (DoD).

Let’s compare this directly with a product team who have a similar pattern in defining done which doesn’t really align with what consumer asked for. If multiple teams are dependent on each other but defining Done differently, can we trust the process? Yes we can, if it’s a common knowledge and have been made explicit.

Forget about the consumer and interdependent teams for a moment. Consider a Product Owner (PO) and the Development team, who has completely different level of understanding about what is done. PO wants a demo of the finished iteration but the “development” team is divided between programmers and testers (reality of many teams). So they tend to assign done on their work to throw it over the fence – Programming Done and QA Done. Even after all this, the “finished” product is sometimes useless as the environment dependency wasn’t considered as a factor at any point of the “development”. These are all part of the mandatory definition of done as a common practice and basics of what we do as a team.

 

Back to the Holy Cow again. So the restaurant kitchen considers serving the food on the table as done. For the Restaurant owner it is NOT Done. It is done for the owner when the consumers pay and leave a good feedback. For the consumers, it is none of those. Consumers only care about getting the “Dinner” done and get the worth of their money.

Now, If we assume Scrum is being used as the framework and compare the roles to visualise the definitions:

 

Done for the Kitchen (Development Team):

1. Order received and picked up by the head Chef
2. Head Chef reads the order and asks one of the Sous chefs to pick it up or started working on it himself/herself.
3. The Chef takes a nice 8oz cut (requirement ignored for simplicity of this discussion) and starts grilling it
4. Chef thinks it’s done as per the order
5. Head Chef calls for the waiting staff to take it out to the table

 

Done for Restaurant owner (SteakHolders.. Oh wait.. Stakeholders):

1. Consumers arrive, approached and seated as quickly as possible
2. Consumer orders food
3. Kitchen cooks and food is delivered on the table
4. Consumers cherish the food
5. Consumer paid, left a positive feedback and the table is rotated

 

Done for Consumer (Clients/Users/Customers):

1. Find a nice steak house
2. Arrive as planned with mates to cherish a moment
3. Steaks ordered
4. Drinks while waiting it to arrive
5. Steak arrives
6. Yum.. Om Nom Nom..
7. Pay and leave for the late night party or some prefer it the other way shown.

 

Examples above highlights a very simple behaviour we have seen, depending on who we are at that moment of time. No one is on sync and why should they, everyone has their own life. We just need to take it into consideration. We need to cooperate and work together so everyone is satisfied; especially the care should be taken from the provider side as they are responsible for the successful delivery to the consumers. That is their business and source of revenue.

 

What’s next?

Stating the obvious but it’s time to take DoD seriously if we aren’t already. Apply it to all work items. If we don’t know the goal we can never achieve it. It is ofcourse negotiable so take the opportunity to discuss, establish and share the common knowledge without bypassing the key personas – the PO or Stakeholders or the Consumers.

 

Rules of Thumb:

• DoD should be made explicit as a discipline
• DoD should be negotiable but a baseline is very important to start with
• DoD should be established pragmatically and cannot be same for all stories
• Without a baseline DoD the product team should not even start working on the story
• DoD is essentially a checklist and should be treated like one at all times. It can change as we learn more about the story implementation.

 

P.S. Religiously, I like my steak Medium Rare and I will snap if I get served a Medium. That’s my DoD. Get in touch if you want to take this discussion further in a nice Steak House around you 🙂