Done undone

As a Product Owner, it is my key responsibility is ensuring that the customer is satisfied with the product.

As the SCRUM Team, it is our key responsibility that we get the story "Done" in a way that the customer will also accept.

Recently, I had a bad surprise when running a new team.

We all work for the same company, but we usually don't work together in the same constellation.

So, we dug head in, at the beginning of the sprint, we defined the backlog.

As PO, I defined the stories and priorities. Then, my team did the Work Breakdown and defined the tasks required for each story.

During the Sprint Review, I couldn't accept a single story as "Done", despite the fact that the team assumed the story was done.

What had happened?

The tasks all got done, but nobody paid attention to the story itself! After all tasks were executed, the story was so complicated that even the developers had to ask each other how to use it - UX was terrible!

A customer was present in the Review and he simply asked "How do you expect me to do this?"

Sorry for the team, I couldn't accept it as "Done", because I personally understood "Done" as "We are not going touch this again. We can tear up the story card because everything is finished".

The failure?

I assumed that the team's Definition of Done was the same as mine, but the team had a DoD for themselves which considered a story "Done" if all tasks were completed - not when the results are usable by the customer!

Lesson Learned

Make sure that the Definition of Done is not subjective.

Take your time in the first sprint. Remove all subjectivity and unspoken expectation from the DoD.

Everybody must be on the same boat. The team, the PO and the Customer should all have the same understanding of the team's DoD.

Make certain that before the first story gets implemented, everyone knows and understands the team's DoD in the same way.