Continuing with our evaluation of Scrum Tools and their role in helping form or strengthen a Scrum Team, this week we encourage you to revisit your Definition of Done.
>Per The 2020 Scrum Guide, the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
That being said, if you have new Team Members, if Products are being released with outstanding problems or things undone, if you haven’t inspected and adapted to the pandemic world of adjusted work hours and expectations, then it’s time to update your Definition of Done.
In Scrum, each iteration of the Sprint cycle produces a potentially shippable product increment. During the Sprint Review session, the Team gets the spotlight. They get to share with the Stakeholders and the Customer the work that they’ve completed over the last Sprint. If the expectations of the customer line up with what the Team delivered, then everyone is happy.
But sometimes that doesn’t happen. The customer comes into the Sprint Review expecting one thing but gets something else instead. So while the Team Members may agree that a particular feature is “done,” the Product Owner or the Customer may not.
In order to avoid this situation, here are seven tips to get you started:
- Have a fully engaged Product Owner. Because the Product Owner is the customer liaison to the Team, they are the critical link in understanding what is most important to the customer.
- Create well-worded, specific User Stories. The best User Stories describe the role of the user/customer, what they want and expect from the product, and what benefit the feature brings. These are the easiest to translate into features for the backlog, and in turn become good requirements and tasks for the team.
- Ask questions. Don’t assume anything. It is ALWAYS better to find out early that your assumptions didn’t meet the customer’s expectations. If something is unclear, never be afraid to ask good questions in order to clarify what the customer wants.
- Estimate well. You might think this doesn’t have anything to do with feature completion. However, it is human nature to feel pressured to meet the estimates that we set for ourselves. A poor estimate can lead to rushed work, which in turn can cause a feature to not be completely done.
- Choose Product Backlog items wisely. By picking complimentary items from the backlog, the Team has a better chance of success. If Team Members choose items that are all across the board, they may miss a critical dependency between items that may not be part of the current Sprint’s backlog.
- Keep your Product Owner informed on your Team’s progress. Communication is critical, and if the Team is struggling then the Product Owner needs to know this early on. In this way, the Product Owner can keep the customer and Stakeholders apprised of issues that may not appear on the burnup/burndown charts.
- Test, test…and test some more. There is no substitute for determining if a feature is done other than comprehensive testing.
