Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:
- small enough to be manageable in a sprint
- contain enough detail to estimate accurately and
- create acceptance criteria that really help define “done.”
POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:
- Story contains actors, problem, and value
- Story should fit in a sprint
- Story should be appropriately documented (does it require wireframes? User-journeys?)
- Value should be obvious, if not, it should be explicitly stated
- Story should have reasonable conditions of satisfaction
- Story should focus on problems, not solutions
Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:
- Show users products that other customers, purchasing the same products as this user has chosen, have bought also
- Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
- Show ratings and percentage of customers who ended up adding the additional products to their basket.
This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.