Does Adding Definition of Ready to Your Team Agreements Help?

In agile, a story is defined as ready, sent through a sprint, and then marked as done when it becomes part of a product incrementA few years ago, I started introducing Definition of Ready to help alleviate a common challenge I was seeing. User stories were coming into the sprint with little information and weren’t making it to Done. The team spent more time talking to the Product Owner about what they wanted than developing it.

As an agile enthusiast, I was aware of the latest updates to Scrum guidelines and introduced Definition of Ready thinking this will solve our problem! I met with the team, setup a few guidelines as reminders of what should be in a story, we were set!  Over time, through retrospectives, these guidelines morphed into something I started to realize no longer made us an agile team.

Where it All Went Wrong

Defining Ready started very innocently. We followed the rules of Scrum and identified ways to improve our process during the retrospective. Everyone was happy, we all walked out thinking, “Great! We solved the problem! We rock!”. Our team had a new set of rules that looked something like this:

  1. Stories must have a design for the interface included
  2. Acceptance Criteria must include all conditions of satisfaction
  3. Data model defined and approved by architect

On the surface, implementing this solved all our problems, it was the magic pill for our troublesome sprints! On further reflection, I saw something that started to look more like a wall, not a magic pill.

Cartoon showing high walls for Ready and Done in the Agile process

The Realization

It is true that stories need a certain level of information to foster a valuable conversation about the “how” , but do they need to be 100%? If the Definition of Ready is so strict, is there room for collaboration? Did everyone participate in the ready discussion? Was there a stop in flow? Are we really adopting Agile Principles?

One of the greatest benefits Agile methods have demonstrated is collaboration is the key to success. I know you just took a step back and said, “But we are collaborating! Everything is READY so we have know what’s in a sprint! This is how we’ve reached a consistent velocity. We reduced/eliminated uncertainty!” If this is your gut reaction, or something close to it, my suggestion would be to call in a favor from your favorite co-worker. Ask them to facilitate a session to check the health of the team, you included. Not sure? Ask you and/or your team a few of the following questions:

  • Is the entire team participating in the ready process?
  • Have you seen delays on starting higher priority items because they weren’t ready?
  • Do any of the ready rules prevent you from continuously delivering value?
  • What feedback in the sprint considered new to the team?
  • Do you feel there is a good relationship with the PO and they are at least 80% available?
  • Do you feel safe to fail?

If you find the majority are answered negatively, there’s likely other issues at play within the team. Making a strict Definition of Ready, essentially turning it into a stage or a gate, isn’t going to solve the teams’ problems. However, creating a stage or a gate has the potential of preventing your team from being Agile. The key, with anything in an Agile culture, is to find the right balance.

Course Correction

Scrum is a prescribed framework meant to help facilitate a team becoming Agile. Creating a bunch of rules so the team can claim they do Scrum doesn’t really accomplish being Agile. Teams should strive for concurrent engineering which focuses on overlapping activities. Stories can then easily flow from development to the users without stoppages. Teams can and should be analyzing, developing, breaking down, and flushing out details for a user story within a sprint, that’s being Agile!

Something as simple as modifying the wording in your Definition of Ready can help avoid stopping the flow of stories and allows for concurrent engineering. Here’s an example of how a simple wording change makes a big difference:

  1. Sample interface designs included, if available
  2. Acceptance Criteria should include as much of the conditions of satisfaction as known
  3. Known Data included

By generalizing instead of making specific, measurable criteria the gate has been removed. The team can determine for themselves if something is ready based on the guidelines established. For some teams, slight changes to the Team Work Agreement such as “be conscious of ready”, “discuss implementation details as a group”, or “ask do you need to know this now” may eliminate the desire to create strict Definitions of Ready.

Improvement Strategy

When I realized our Definition of Ready read more like a defense strategy I pulled a play from our play book. TeraThink’s Team Health Assessment Play is a great tool to use in place of your typical retrospective or on it’s own. It provides nine health attributes for your team to assess how well they are doing. It includes tools to scale for multiple teams and steps for how to identify changes for your team.

If you have an inkling your Definition of Ready is a bit strict, hold a retrospective and run this play. We even provided templates and handouts! Make sure to ask your team for their ideas in solving the problem. Also, don’t forget to take a long hard look at those team agreements.  In my experience, the challenge is usually somewhere between overthinking Scrum and under-thinking how to adopt Agile principles.

Remember what Scotty taught us in Star Trek III, “The more they overthink the plumbing, the easier it is to stop up the drain.”.

[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]