Wednesday, August 28, 2013

The Definition of Ready - a Scrum Smell?

Definition of Ready
I’m going on the assumption that you already know of what this term / tool means in the context of agile development so won’t be starting with re-explaining it. Have a look here if you are still unsure.

Scrum referers to a “Definition of Done” and to move a team into scrum involves creating this artifact. Creating a “Definition of Ready” is not part of scrum. It is a tool that an agile coach needs to keep in their toolbox but I would recommend not pulling this one out too quickly and certainly not as standard procedure.

The reason that “Definition of Ready” is not a scrum artifact is because you shouldn't need it. If scrum were understood completely, then “being ready” is implicit and not needed as explicit. When I have to pull this tool out of my agile bag of tricks, it is always a sign that there is dysfunction in communication between the product owner and the delivery team. The Definition of Ready is a band aid fix to put in place so that progress can continue while I begin working on resolving the root cause of the dysfunction.

This dysfunction can surface when a product owner and/or delivery team are new to agile and one or both sides are not familiar with working with agile requirements and it is causing friction. Coaching the product owner in what a healthy backlog looks like and in what is required of their role to keep a team moving is one side of the coaching. Coaching the delivery team on being able to work with vague requirements is the other side. Sometimes the issue is a when a previous waterfall team are unable to make the conceptual leap of working without extensive documentation - requirements, architectural and specification documents.

Depending on the root cause, coaching items that may go on my coaching backlog might include :-
  • Playing to win
  • Story writing
  • Story splitting
  • Story map (as a backlog management and prioritization tool)
  • Incremental design and architecture
  • Delivering business value as a team
  • Working with a product owner
  • Product backlog management
  • Backlog grooming
  • Backlog transparency
  • Delivering working software
  • Small releases
  • Agile requirements
  • Emergent design
  • Tests and code as documentation
  • Retrospectives to address communication issues

Once the issues have been resolved, you can throw the definition of ready out. Remember in agile we are trying to make our processes as lightweight as possible. Removing an artifact that is redundant is keeping things lean and a good practice. Make it a celebration event with the team too. Something like “Hey - we don’t need this anymore. We are on the road to high performing!”


  1. you could say the same about definition of done. most places you need an explicit policy indicates you have a complicated situation that is not well understood. If a skilled team is doing XP dev practices they probably don't need to write down a definition of done, the build tells them every time they have an issue.

  2. Yes and no. No because Definition of done is part of scrum, definition of ready is not. Whilst definition of done is not one of the scrum artifacts, it is in the scrum guide. Therefore, if you are doing scrum "by the book" you will have created a definition of done.

    The yes part is that I agree that a Ri level team (as in Shu-ha-ri) can do without a definition of done. They are in a state where they can break and make their own rules. Also they will understand the why of having a definition of done and in doing so, moved past the need for having it.

    XP does not describe a definition of done. Coming from an XP background I am used to working without it. I think that the XP concept of "Playing to win" encompases the definition of done and makes it redundant.

    So saying, I find Definition of Done is a good tool for teams starting out. However, definition of ready not so much for the reasons outlined above. Definition of ready means something is broken and needs fixing. So to introduce it before anything is broken goes against the philosophy of "if it ain't broke, don't fix it".

  3. First, I do not think we should do any practice because XP or Scrum includes them. XP and Scrum should simply be frameworks to help us see our issues and improve within and even drop when they get in the way of the ultimate goal of delivering customer focused high quality sw.

    It seems all explicit policies can be used to help us see what we are doing or would like to be doing. It follows the principle of transparency and helps us see, when necessary, what is happening. The visibility can help people see how crazy the situation is. A team I worked on, all very experienced with 3-6 years agile experience, started with the equivalent of a working agreement (though we did not call it that). It made the goal of how we wanted and expected each other to act on the team. A visible reminder that we adjusted for the first few months until we were actually behaving that way on a consistent basis. At some point we took it down because it was who we were and we did not need that but something else to help us improve. Most teams have different areas of Shu-ha-ri in different areas and should pick things that help them in their weakest areas.

  4. Yes and no. No - in that I think a brand new Shu level team you do have to to do it by the book. I know my introduction to XP was by the book and I'm glad for it. If you start with Scrumbut your chances of making the transformation are not in your favour.

    Yes - "pick things that help them in the weakest areas" is exactly what I am talking about. I am suggesting that the "Definition of Ready" is a tool to use when there are issues around sprint planning, grooming and/or communication issues between a delivery team and product owner. But if there are no issues - don't use it.

    My point is that "Definition of Ready" is not needed as rote when creating a new team. If the team 'aint broke (in this area), then don't waste time and energy on something that is not needed.

    I am not dismissing the "Definition of Ready" as a tool. Use it when you need it. Once you have it in place, you will need to work at the larger issues of why you had to put it in place.