Generally speaking it is helpful to have specific agreements in place as to what it takes to move a story from one column to the next on the board. You can think of these agreements as policies. They are effectively checklists which say “these things have to be true in order for a story to move into this column.” If your team is delivering things in an iterative fashion, it can be very helpful to have a clear definition of when things are “ready” to be considered for inclusion in an iteration. I like to call this list of conditions a definition of ready. This is a technique I learned from Bob Payne and other coaches at LitheSpeed. I’m not sure where it originally came from.

What Is It?

The idea is that you have a specific list of conditions that stories meet before they can be considered for consideration during iteration planning.  The nature of what can be included in a definition of ready varies, but here is a partial list of things that I see quite often in the teams I work with:

  • Small enough story
  • Acceptance criteria
  • Testable examples
  • Wireframes/prototypes/mockups or other models
  • Dependency list
  • Impacted stakeholders
  • Product Owner ok
  • Approvals from compliance, security, and other governance groups, where applicable

These are things that can be on a definition of ready.  I very rarely see all of these things included.  Usually the definition of ready I try to shoot for includes:

  • Small enough story
  • Acceptance criteria
  • Testable examples
  • Mockups or appropriate model (where appropriate)
  • Dependency list
  • Impacted stakeholders

The appropriate definition of ready is specific to a given team and is something the team determines as it is starting its work.  This is a great discussion for the team to have as they are preparing to start working together.  As with many other techniques, the conversation in creating a definition of ready is invaluable, but the actual result of the discussion can be fairly helpful as well.

A Way to Define It

Defining ready is another place where sticky notes, affinity grouping, and dot voting can come in handy, but generally the items that are included in the definition of ready are few enough in number that a general discussion with the group about what needs to happen in order for a story to be brought into an iteration is sufficient. I usually introduce the idea and then have team members suggest possible list items. After the energy seems to die down on adding new items, we’ll go back and review the list.  My experience has been that there will be some items that are no-brainers, there will be a few items which are questionable whether they apply to every story, there will be others that are questionable whether they need to be done before work on a story starts, and there will be others suggested that may not need to be done at all.

This discussion is particularly interesting with teams that are just starting to make the move to agile.  The discussion starts off easily enough.  Team members just start calling out ideas of things that they think should be completed on a story before it is brought into an iteration. (Note that the assumption here is that the first thing that occurs in the iteration is developing code, be it test code or production code.) As they continue listing items, the size of the list starts to leave certain impressions with people.  In facilitating these discussions, I can often see the light dawn in people’s eyes as they realize that the list is getting excessively long.  Inevitably I’ll hear the oft repeated phrase in these types of discussions “We’ll never get anything ready if we have to do all this.”  By this point, the list more often than not includes things such as data model designed, database built, architecture sign-off, permissions set and similar items.

It’s at this point that you stop asking for new items to the list (chances are there aren’t many that they could actually identify) and ask whether everything should be on that list.  This is the chance for the team to reflect how often some things occur and whether some things are needed or not. During this discussion, items are removed from the list, some are tagged with “when applicable” and in-depth discussions occur about one or two things that a few members of the team hold on to as if their lives depended on these things happening on every story.  If you have some of those items, the best thing is to leave them as part of your definition of ready for the time being – discretion is, after all, the better part of valor.

The Definition of Ready is Not Definite

The definition of ready is not set in concrete, and is open to revision.  This is not to say that the definition of ready can be ignored whenever it’s convenient, but rather the team can intentionally discuss if their definition of ready is working for them during a retrospective and based on experience make revisions to it.  That’s pretty much the case with most team agreements.  They are lines in the sand so that the team can have a common understanding of how to work together, but if members of the team find that they are having difficulties working together under their agreements, than can change them via a discussion with the team.

A bit of discussion about whether things should be included with a definition of ready is good, but if the team has not worked through a few iterations together already, they are not really going to know what they do and do not need, so don’t spend too much time arguing fine points when you first create the list.  If the team can’t decide fairly quickly whether something should be taken off the list, come to an agreement to leave it on or take it off and then make a point to revisit that particular item in an upcoming retrospective.

A definition of ready goes a long way in helping to define what just enough analysis is.  The team in effect agrees to the specific level of information that they need to start testing and developing a story. For those of you out there who have always wondered how to tell when you are “done” with analysis, a definition of ready provides that too. This blog post is a topic taken from my next book Beyond Requirements.

– Kent

About Kent McDonald

Kent J. McDonald is a B2T Training Senior Instructor and stives in uncovering better ways of delivering value by doing it and helping others do it. His more than 15 years of experience include work in business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, performance marketing, human services, nonprofit, and automotive. He is a certified Scaled Agile Framework Program Consultant (SPC) and active in the business analysis and agile software development communities helping people share stories about what does and does not work. He shares those stories at beyondrequirements.com in addition to presenting at and helping organize several local and international conferences.

Pin It on Pinterest

Share This