Over a million developers have joined DZone.

You’re Doing It Wrong: The Definition of Done

In this article, Gil Zilberfeld considers the word "done" in agile practices and how we are using the term all wrong.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

In this series, we’re taking a look at what we do in agile, those pesky practices, and why we’re doing them. The purpose is the key here, and if you’re not getting the benefit, you might be doing it wrong, so try something else.

So, let me ask you a question:

Are you done, done-done, or done-done-done?

What does done mean anyway?

To answer this question, let’s look at why defining “done” is important, especially in the iteration scope. As with many agile practices, it boils down to trust between the business people (and their representatives on Earth, product managers) and the development team. As you’ve probably read already, agile practices are supposed to rebuild the lost trust. The definition of done is another pillar to support the structure.

“This is how I see it working,” says the product manager.

“Ok”, says the developer

“I get what the feature does, I’ll go build it”.

“But not like last time. Do you really get it?” the product managers timidly asks.

Because last time, she was surprised at the demo. Then the team needed to rebuild the feature because “they got it” but in a “different way”.

The Definition of Done is a surprise suppressor. It is an agreement in a common language of “what should work”. The level of details needed in order to get to this agreement is in inverse proportion to the trust between the business and the team. The bigger the trust, the less details are specified.

“We got it last time, but you changed your mind when you saw it”, continues the developer.

While an agreed upon Definition of Done is a good surprise suppressor, it does not mean there won’t be changes on the way. Agile processes are built on feedback, and once the product manager reviews what was actually built, she will say “it’s exactly what I wanted.” But in most cases it will be “Yes, but can you change…”.

Because that’s how people work. They react based on feedback. And the processes people use need to support people, not the other way around. Our process cannot disallow changes.

So if you’re feeling the Definition of Done as a contract, you’re doing it wrong. It’s more of a guiding light, giving a direction, but the direction can change based on new information.

So the Definition of Done is what we have before we work. What happens at the end?

Next time, we’ll continue talking about Done. With bugs.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

business,scope,agile practices,team,people,managers,practices

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}