We do Scrum, but…
“Scrum — We often have to cut corners on the Definition of Done”
Are you serious? — episode 12
Does this sound familiar:
“We promised to deliver the functionality by end of this month. We can’t let our customer down by being too late”.
“We need to deliver these tickets because we committed to doing this within the Sprint”.
And then followed by: “Let’s skip the ….* part of the Definition of Done. We can tackle that next Sprint, or the Sprint after the next one.” For * fill in what’s most vivid to you. For me it’s: let’s not do a full regression test, it’s too cumbersome at this point.
What does this mean?
It means that you (and the whole team) do have a common ground when an item is “Done”, when work for an item is complete:
“(Scrum Team …members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.” — SG
It also means that you choose to ship an item that is NOT complete:
“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review.” — SG
and it means that you are not transparent. The state of the product increment is unclear:
“Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts.” — SG
Also: you might (or rather — you almost certainly will) introduce TECHNICAL DEBT. Decisions are made to release before all of the necessary actions are executed to be “Done”. This builds up technical debt comprising those uncompleted changes. The longer it takes to repair the technical debt, the more difficult it gets to repair it.
Why would you choose to skip parts of the Definition of Done?
- Is it pressure from outside the Development Team? OK. But what do customers hate more? A faulty product delivered in time or a correctly working product delivered late? Trust is hard to gain but easy to lose. The consequences of a faulty product almost always outweigh “timely” delivery. And also:
“They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” — SG
- Is it pressure from inside the Development Team due to what was committed during the Sprint Planning? Well, how can you achieve it while skipping parts of the Definition of Done? How can you deliver a “Done” increment while skipping parts of the Definition of Done?
- Is a part of the Definition of Done adding no value whatsoever? Then it might be time to change the Definition of Done and remove this part.
Bottom line
Skipping parts of the Definition of Done results into delivering an incomplete increment. Incomplete according your own Definition of Done, which the Scrum Team established. The Definition of Done is pivotal for the Scrum Team to deliver a complete working product increment without technical debt. It is also pivotal to raise transparency, one of the three pillars of empiricism.
You can’t deliver a “Done” increment while skipping parts of the Definition of Done.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
Join us on Slack!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to connect with us on Slack to share your thoughts. Also if you are interested in publishing in Serious Scrum.
Thank you for taking your time to read seriously.
My twitter profile is https://twitter.com/WJAgeling