One of the earliest ideas you learn as an agile practitioner is “Done, Done, Done”. There’s a lot of thinking behind it, but for me it boils down to trust. When you don’t know what “done” means, the next person who gets you’re deliverable might be surprised.
As a rule, we don’t like surprises.
So regardless of when it’s going to be delivered, what the quality is or what it contains, it is better to achieve a mutual understanding of what “done” really means. If possible, prior to the delivery.
In agile teams, a “done” story is usually defined as a working work flow in the software. Mature teams put enough effort in the story to make sure it works – automated tests, code review, deployment automation – whatever is close to the team’s definition of “working software”.
If the team has all these in place, it seems that if we define all the stories up front, we’d actually know how much “done” we are in the feature, release or product level.
It’s never done until it’s good enough to ship
We don’t like big preparation upfront in agile, because things will change. The bigger they are, more changes will be introduced. It applies to requirements, design, architecture and plans.
If that’s true, then we can never really know how much on track we are. If the team is currently working on story number 25 out of the original 50 we came up with originally for the release, are we really half-way?
Things may change over the next couple of sprints – we may learn things that will drive us to drop or add stories, and maybe replace them with others.
In an exact point in time, we don’t really know how much done we are. And that applies at the feature, product and portfolio level. We can only decide if we’re ready to ship. If the feature, product or portfolio are ready for release. Someone, usually a PO or equivalent has to say – ok, this is good enough, ship it.
Even at the story level, we won’t always have time to code and test every path. So even a “done” story may not be really done, but still be good enough to ship.
That’s ok. Because regardless of level, from story to portfolio, getting to 100% done-ness is waste. We don’t need all the stories or features in there to ship. A good product owner knows when it’s good enough to ship.
A smart one will ship many times to get feedback and learn, understanding the product is never “done”.
We’re really never done. And that’s ok.
| Reference: | The “Done” Fallacy from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
