You’re not done when you have a Definition of Done
Agile coaches and trainers will tell you you need a “Definition of Done“. Everybody needs to understand and agree what it takes to put a User Story in the “Done” column on the team’s board. Does “Done” mean “released to production and used by the end user”? Or does it mean “ready to handed over to another team, who’ll do acceptance testing”? Agile pundits will vigourously debate what Done should mean, but there is no one definitive answer. Each team has to agree on their own definition. My only advice would be to define Done as far as possible in the value stream where you still have control or influence.
(Re)Defining Done has a large impact
In one team, developers called their stories Done when they were given to the integration test team. Unfortunately, most stories didn’t stay Done for long, as the testers invariably found many issues. Most of the time, the “Done” story didn’t even start up in the test environment. To which the developers invariably replied: “But it works on my machine!” 🙂
After making a Team Quality Manifesto, the development team decided to update their definition of Done with “It’s only done when another developer has tested the code on their machine”. In the retrospective of that release the testers remarked that quality had increased enormously: it had become really hard for them to find any bugs.
Changing that Definition of Done had a small, but important psychological effect: the developers didn’t mind that testers, who worked on another floor, in another team, couldn’t get their stories to install or run correctly. Testers are paid to find bugs, aren’t they? However, the developers did mind that their peers found issues in their code. It was just too embarassing, so they made sure that their stories were Really Done.
The Definition of Done is useful. But it’s not enough.
User Story State Transitions
As we work on our User Stories, they go from one column to the next on the board. Each move is a state transition. Each transition has a set of guard conditions that must be satisfied to make the transition.
Shouldn’t we define the other transitions? Would that be helpful?
The definition of everything
I’ve seen teams struggle with “immature stories”: a set of stories is chosen for the iteration or release. The team starts to work on them, but many of them quickly end up in the “Blocked” box, to the frustration of everyone involved. If this happens more often, the team can see if there are common causes for these blockages. Was it because we used a new, unknown or immature technology? Was it because another project, on which we depended, was late? Was our external partner not ready? Were the agreements not clear? Were the people we depended on not available as agreed?
Often, these causes can be grouped in a few clusters and we can quickly determine for each project which of these clusters could endanger that project. For example we can say: for integration projects, the definition of “Ready to be included in Iteration Planning” includes that “a test integration server is available and has been confirmed to work.”
A column on the board is a promise for a conversation
“Oh no, are we going back to phase transitions now? I thought we were doing Agile, not Waterfall!”
Try this at home: ask your team “What are the criteria to move into this column?” Are the criteria clear? Maybe we should clarify them. Do team members disagree in which of two columns we should put a story? Maybe the extra column doesn’t add any value and we can eliminate it. Are there stories that we don’t know where to put? Maybe we should add a new column. Each column, each transition must bring value. What extra information do we have if we move the card from column X to Y? Who uses that information? Which action will you take based on that information. What information do we get from being able to see at a glance how many (or which) cards are in a certain column? For example, if the “Ready for iteration planning” column is empty, we might not have enough stories to fill the next iteration. Shouldn’t someone start to work on that asap?
Start the conversation in your team. You might uncover some issues, simplify your process and make essential information visible.
