Home » Software Development » The “Done” Fallacy

About Gil Zilberfeld

Gil Zilberfeld

The “Done” Fallacy

yodawgOne 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.
(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments