Definition of Ready

A few weeks ago I had the pleasure of having lunch with Alan Dunne from Alcatel-Lucent here in Ottawa.  Alan has commented on a couple of our AgileSoC blog posts in the past, and is a shining example of someone who has been using agile techniques with good results in his team’s FPGA development.  Over the years Alan has been diligently refining the typical software agile techniques for his FPGA team.  It was Alan that introduced me to the “definition of ready” (let’s call it DoR  from here on in).  A DoR is a corollary to the “Definition of Done” (aka DoD) which Neil blogged about a while ago (review it here http://www.agilesoc.com/2011/07/31/by-example-done-vs-done/).

What is the definition of the DoR?  Similar to the DoD, DoR is the criteria applied to every Product Story (aka feature or requirement) before the story is accepted into your workflow (or iteration).   It is the hurdle that every story must get over before the engineering team should add it to their todo list (e.g., sprint backlog if you’re using scrum, or your Kanban board). The DoR can be applied as the input criteria before your implementation.

Simply put, every product story should follow a simple three state process:

  1. a feature is considered from the Backlog, but must pass all (or most) of the items in your DoR,
  2. the feature is implemented and verified, and finally
  3. must pass all of the items in your DoD.

The entire cross-functional team is responsible for creating (and presumably agreeing to adherence to) the DoR.  As with all things ‘agile’, the definition is permitted to be refined and adjusted throughout the project e.g., discussed during a Sprint Retrospective.  As well, the formality of a DoR can range from a checklist that must be strictly adhered to, to the “back of the napkin” / whiteboard session to indicate that the story is ready to proceed to the next phase.   It’s up to the team to decide what is appropriate.

While it’s true that this is another step in your process, it should be a step that is considered to help accelerate the implementation rather than slowing it down.  Having the entire team accept a DoR ensures that you are increasing your chances for success because everything you’ll need to complete the work is lined up (or is being lined up) to assist the completion.

While the specific elements of a DoR will likely be different for every team and project, there are a couple of common elements that I think a DoR should contain:

  • What:  Is the goal or end-result of the story clearly defined?  i.e., is the expected behaviour or coverage goal as clear an unambiguous as possible at this stage of development?
  • How: Have you considered how to build the feature?  It doesn’t have to be much, but some thought about how to build and integrate the product story into the existing working product.
  • Who / Resources:  Are all the necessary resources (i.e., people, tools, IT infrastructure) available and committed to the product story to have a reasonable chance of completing within a reasonable amount of time?

What would I include in a DoR?  I like to see the following:

  • Is the expected behaviour as clearly defined and understood as possible?  While this clearly leads into defining some acceptance criteria and is a prerequisite for the Definition of Done,  at this point in our development we simply need know that the behaviour expected is as clear as possible.
  • Have I given some thought on how it could be implemented?  I prefer creating a quick UML class and sequence diagram of how the pieces work together.  My key goal here is to define what impacts will this new feature have on the existing work.
  • Should I create a short document with the design?  Since I use UML I like to create a short document that glues the UML diagrams together.
  • Do I have a realistic handle on how long it is going to take to build?  It won’t be right, but it needs to be a reasonable estimate given all that I know.
  • Do I have all the resources I need to complete this task?
  • Can I see any dependencies that would block me from starting or completing? e.g., will I need to complete some other task? or wait on someone else? or some script is required before I start this product story.
  • Does everyone agree?  Getting agreement is an important part of this checklist.

My last point is your DoR should be viewed as an implicit agreement that should not be followed dogmatically.  Commitments made during the discussion may change even while your implementing the product story — that’s the nature of the work we do… priorities change frequently.  To summarize: use the DoR to get all your ‘ducks in a row’, but to stretch the metaphor, don’t expect the ducks to continue to walk in a straight line.

What would you include in your DoR?

Share/Bookmark

About Bryan Morris

I have been doing ASIC verification for over 13 years, and before that I did about 15 years of embedded software design & management. The software world dealt with increasing complexity by creating these agile development techniques; I think hardware can adapt and evolve their own agile techniques. I'm working as a consultant now and see where agile practices can help hardware development get a much-needed productivity boost. I'd always welcome your thoughts: bryan.morris@agilesoc.com
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Definition of Ready

  1. Pingback: User Stories: Ready, Set, Go! part-2

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>