A couple of recent engagements and experiments have confirmed a pretty long held thought by many I have worked with in software development, quality starts way further back in the SDLC than most give it credit for. Certainly those who are business focused, and maybe not familiar with developing a software solution may underestimate the hugely important role they play in helping the development team to deliver quality, at pace.
Definition of Done vs. Definition of Ready
So what’s the difference, simply put the DoD is an upfront agreement between the development team the PO, and the Stakeholders about when something is considered done, in a lot of cases this can be the point something adds business value, or is in a production environment, or is handed to QA. Before we lose focus by arguing the rights and wrongs of the options listed! Let’s move on. DoR, is an agreement between the software development team, and again the PO and Stakeholders about the information that is provided to the team. For those unfamiliar with how this is done, at its simplest level user stories are the preferred method here. Let’s look at an example, in the simplest possible way;
Example user story:
As a user of an ice cream, I want to be able to eat the ice cream without getting my hands messy.
The above user story at its most basic may appear to give someone all the information they need to create a solution to your ice cream eating desires right? Consider this a little, you give the requirement to someone who can help you eat ice cream, they then return to you with some ice cream in a bowl, with a lovely spoon for you to use. Your reaction may be “I’m not walking down the street with a bowl and a spoon, to eat my ice cream”
A definition of ready user story for the above may look like:
As a user of an ice cream, I want to be able to eat the ice cream without getting my hands messy, using only one hand, in any location of my choosing, the wrapper should be recyclable, and it should not need anything other than the ice cream and the solution to consume the ice cream. I will test this by attempting to walk down a road, whilst eating my ice cream with only my hands.
It’s now clear to the solution provider that a bowl and a spoon is not the answer here, you are more likely to get a good old fashioned wooden ice cream stick, or a helium balloon to hold it for you or something. The point being that if you agree up front the level of information that a user story requires, before it can go into a backlog, and you invest the effort in doing that. You may well spend more time being able to eat ice cream, than being in meetings talking about what you really meant with that one line description in your user story, and your product will be to market faster and you and your team will be happier. Interesting what an ice cream stick can show us some days.
If you would like to talk to us about ice cream sticks, definitions of ready, project inceptions, or anything software development related please do get in touch or call us on +44 (0)161 533 0595.
