As the scrum guide states "When a product backlog item or an increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per scrum team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the scrum team and is used to assess when work is complete on the product increment."
As a Scrum Master,I coach my teams to continuously expand our Definition of Done. Simply speaking, steer the team to reduce the amount of work left to accomplish after they consider it done (e.g. release, smoke test in production, documentation). When I start with a new team, we write the definition of done together. As a part of this exercise, teams write a fundamental checklist that needs to be done in order to mark a story as done. We review it in every sprint planning meeting. Not that I am surprised but my team hasn't suggested a single change in the definition of done from past 6 months. Thus as a part of the retrospective, I thought to bring the definition of done under scrutiny.
Exercise to improve/expand the definition of done:
With your team and within your organization,reflect on the amount of work that needs to be doneaftera team considers an increment “done”. Help both the organization and the team to change processes and practices to decrease this amount of ‘undone’ work. After a lot of thought, I got an idea. I got my team together to document the lifecycle of a story once it enters a sprint. I made them draw it on the whiteboard. After around 30 minutes of good conversation, We learned that every story in our sprint transitions through 5 major steps to reach production.
Step 1) DevelopmentCode to meet the acceptance criteriaCreate Unit testCreate Functional testCreate Integration testStep 2) Run TestsRun Unit testRun Functional testStep 3) IntegrationDeploy branch to staging environmentRun Integration testRun Regression suitePut the pull request out for peer reviewAddress the review commentsPull request approvedStep 4) Pre ProductionDeploy branch to Pre prod environmentManual Smoke suite runStep 5) Bundle stories completed in the sprint for Production releaseCreate Change requestCreate a backup production imageDeploy to productionManual Smoke suite runMerge to master
Once you have a clearly visible picture, its time to ask some questions to your team. After all, one of the keys to being an awesome scrum master is to ask the right questions:
- Where are we spending most of the time in the cycle?
- What are the steps that can be considered waste or do not provide significant value?
- What are the steps which can be automated easily?
- What are the steps which happen after we mark the story as done?
- What are the steps we repeat often?
Not to my surprise, the team pointed out a number of improvements. To list a few:
We decided to automate our smoke suite as it was manual
We agreed to experiment with feature release a.k.a " releasing each story to production".
Closing thoughts: I loved the outcome and got me excited to write this article. Previously we were accustomed to bundling stories to make a release which use to go out every 2 - 3 weeks so the definition of done for each story was to put it in "Ready for deployment to production" state but after this exercise, we now release each story into production which means my definition of done is changed to "Deployed to production". This has resulted in faster delivery, frequent feedback from the customer, easy to manage, better quality and multiple other benefits. We would have not thought in this direction without this exercise.
Now we deploy each story into production.Smaller, coherent changesets transform into debuggable, understandable deploys.If we’ve learned anything from the recent experiment, it’s that velocity of deploys and lowered error rates are not in tension with each other, they actually reinforce each other.When one gets better, the other does too. So by slowing down or batching up or pausing your deploys, you arematerially contributing to the worsening of your own overall state.
As Scrum Teams mature, it is expected that their definitions of "Done" will expand to include more stringent criteria for higher quality.
When was the last time you revisited your definition of done? How are you improving your definition of done? Share your thoughts and suggestions.
