Agile Definition of Ready: Pre-Flight Checklist

While agile teams often build the plane mid-flight, incorporating a pre-flight checklist can ensure a more consistent trajectory.

What Is the Definition of Ready (DoR)?

In Agile development, the Definition of Ready (DoR) is a commonly used technique that determines when a user story or task is considered ready for implementation. It entails a set of well-defined criteria and conditions that the work item must meet before the development team begins translating concepts into code.

At its core, the DoR acts much like a pre-flight checklist before a product backlog item earns its ticket into a Sprint. Just as a pilot ensures every switch is in place and every indicator is green before taking off, the DoR ensures that we equip a user story with all it needs for a smooth development journey.

Why Is the Definition of Ready Important?

The Definition of Ready is important because it acts as a proactive measure, ensuring that work is well-prepared before entering a Sprint, maximizing the chances of completing the task in a single Sprint. However, some argue that an over-reliance on the DoR might hinder adaptability.

Consider a familiar scenario: a team selects a user story for the upcoming Sprint without delving into its details. It’s like a plane taking off without a pre-flight check—potentially leading to unforeseen challenges and, in extreme cases, even complete halts.

With a Definition of Ready, it’s like going through a checklist, ensuring all bases are covered. This review greatly enhances the likelihood of finishing tasks in a single sprint, avoiding ambiguity and external holdups.

Completing work within a single sprint is crucial because it allows for faster feedback loops and ensures a steady flow of value to the customer.

The Definition of Ready is a checklist forged from past experiences, helping us bypass previously encountered problems.

Some experiences are best left in the past. One example that sticks out in my personal life is our clogged shower drain. My heartmate only pulled that slimy heap of hair from the shower drain once before insisting we use hair catchers.

“An ounce of prevention is worth a pound of cure.”

- Benjamin Franklin

Essentially, a well-defined Definition of Ready plays a crucial role in ensuring that items in the Product Backlog are refined and ready for implementation. This up-front effort ensures that when items are pulled into a Sprint or development cycle, they are well-understood and have met the necessary criteria, making the entire process more efficient and productive.

Benefits of a Definition of Ready

A Definition of Ready (DoR) brings numerous advantages, such as task clarity, risk reduction, and heightened efficiency. While the benefits of adopting a DoR are evident, there’s a caution against overextending its implementation.

Improves Clarity

Checking that a PBI is ready for a Sprint ensures that every team member understands exactly what they need to do. This preparation prevents confusion and ensures everyone is on the same page. It acts as a guiding light, shedding away ambiguity.

Reduces Risk

One of the significant advantages of a Definition of Ready is its ability to spot potential issues, dependencies, and constraints early in the process. This proactive identification minimizes the chances of encountering unexpected hurdles during development. The team paves the way for a smoother development by addressing these challenges upfront.

Boosts Efficiency

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

- Abraham Lincoln

With a well-defined set of criteria in place, a Definition of Ready significantly enhances the efficiency of the development process. This clarity means team members can confidently jump into their tasks, knowing precisely what stakeholders expect. It eliminates the need for constant back-and-forths or time-consuming clarifications, allowing for a more fluid workflow.

Improves Planning

A clear Definition of Ready empowers the team to decide which user stories to tackle first. It provides a structured approach to determine which stories are ready for development and which may require further refinement. This capability enables the team to focus on tasks that offer the most value toward immediate objectives and goals.

Improves Customer Satisfaction

A cornerstone benefit of a Definition of Ready is its inclusion of acceptance criteria, which serve as the foundation for comprehensive testing. This approach guarantees that the developed feature aligns seamlessly with the desired quality standards. Consequently, it bolsters the overall integrity of the end product, instilling confidence in both the team and stakeholders alike.

Promotes Collaboration

A Definition of Ready fosters a culture of collaboration within the team by advocating for early discussions about requirements and expectations for each user story. This dynamic approach strengthens communication channels and ensures a collective understanding of product goals.

Lessens Rework

Embracing a well-defined Definition of Ready safeguards against rework or late-stage changes, leaving more hours per day to focus on delivering value. This strategic approach conserves valuable time and effort and streamlines the development process. The team can channel their energies towards forward progress, confident in the clarity and completeness of the tasks.

Promotes Transparency

Transparency is a cornerstone of Agile development, and a Definition of Ready is pivotal in achieving it. Making the criteria for commencing work on a user story visible to all team members, stakeholders, and product owners ensures that everyone operates from the same understanding. This transparent approach lays the foundation for an inclusive culture.

Promotes Consistency

A well-defined Definition of Ready (DoR) provides a clear and standardized process that the team can consistently apply. This predictability is valuable because it lets team members know what to expect, increasing efficiency through repetition. It establishes a familiar framework, reducing uncertainty and enabling flow.

Improves Predictability

With a Definition of Ready in place, teams gain a heightened ability to predict when they’ll complete the work, as the time to finish work items stabilizes due to the reduction in blockers caused by lack of clarity. This predictability becomes invaluable in managing stakeholder expectations and facilitating efficient forecasting and planning.

When Is Definition of Ready Created

Consider adopting the Definition of Ready when your team faces hurdles in predictability, Sprint completion, or story clarity. The team needs to recognize the appropriate timing, though others may advocate for creating a DoR at the initiation of a team.

Teams often establish a Definition of Ready when they’re newly formed or beginning work on a new product. While it may seem like an ideal time, it’s important to consider if you’re addressing a genuine issue. Each tactic solves specific problems, so the tactic may not be necessary if your team fails to face that challenge. Avoid introducing unnecessary bureaucracy and overhead.

Definition of Ready Format

The Definition of Ready (DoR) format varies between teams, commonly appearing as a concise bulleted list of criteria.

Some teams incorporate the DoR into their project management software as a checklist or a set of standard fields. While not mandatory, this approach can enhance consistency.

Maintaining brevity to ensure manageability is crucial, akin to how a pilot uses a concise pre-flight checklist rather than reading the entire plane manual.

Definition of Ready Best Practices

Drawing from my experience, here are recommended best practices when utilizing a Definition of Ready. Each practice addresses specific challenges I’ve witnessed teams navigate successfully.

1. Be Clear and Specific

Clear, concise, and easily graspable criteria in the DoR are essential. Ambiguity can deter team members and diminish the process’s effectiveness.

2. Keep It Lean

Streamline the DoR for efficiency. Prioritize crucial elements and lessons from past experiences. Skip redundant details already enforced by other systems. A leaner approach keeps the focus on essential criteria.

3. Enable Shared Ownership

Foster a sense of shared team ownership of the DoR. Involve team members in shaping and refining their criteria. Avoid imposing it from above; engagement drives compliance, effectiveness, and innovation.

4. Be Consistent

If your team decides that they’re going to use a Definition of Ready, apply it consistently. Imagine if pilots randomly skipped items on the checklist—it would lead to chaos and potential disasters. Similarly, an inconsistent DoR can lead to confusion and hinder progress.

5. Retrospect

Periodically revisit the DoR to align with evolving team needs and integrate insights from past sprints. It’s crucial to maintain criteria that facilitate a seamless process. Additionally, occasionally gauge the team’s perception of the value derived from adhering to the DoR. This flexibility ensures adaptability when new approaches are warranted, balancing consistency and refinement for ongoing effectiveness.

6. Transparent

Ensure that the team shares the DoR where everyone can access it and communicates changes made so that people acting on autopilot know and can adjust. This transparency creates a shared goal that everyone can work towards instead of turning backlog refinement into a competition to see who’s competent enough to get PBIs through and into the process.

7. Just in Time

Timing is key when applying these criteria. Ensure you have enough Product Backlog Items (PBIs) refined to support the team’s work intake process, be it Sprint Planning or the steady flow of a Kanban team. Refining ideas too far ahead can result in wastage, as there’s no guarantee our focus will align with the pre-refined work.

On the other hand, refrain from overcompensating and waiting until the team is actively pulling in work to apply the DoR. A deferred application could address significant issues too late, potentially postponing valuable work until we can resolve dependencies or ambiguities.

Definition of Ready Anti-Patterns

As an Agile Practitioner, I’ve encountered a series of anti-patterns surrounding the DoR that teams unknowingly apply. While these approaches may seem reasonable, they tend to amplify problems in practice.

I’ll delineate these practices to explain why they’re adopted and why they often fall short in effectiveness.

Not Counting Refinement Against WIP Limits

Contrary to common belief, refinement comes at a cost. We reduce the team’s capacity to deliver value by increasing the efforts required for refinement. Balancing how much you refine is vital, ensuring a steady flow into your work intake process. The aim is equilibrium between delivering and planning.

In my experience, teams often receive more work than their capacity allows. It’s impractical to refine everything, knowing you won’t get to it all. Focus on refining enough to align with your capacity for completion.

Prioritizing the Contract Over the Collaboration

The primary pitfall many teams encounter with a Definition of Ready is considering it a binding agreement. This mindset contradicts one of the core values outlined in the Agile Manifesto.

“Customer collaboration over contract negotiation”

- Agile Manifesto

When relying on a checklist to assess if a PBI qualifies for selection in a Sprint, it’s simple to see it as a rigid contract rather than a necessary discussion.

This zealous insistence on checking boxes is the very anti-pattern that most thought leaders try to avoid when they advise against teams implementing a Definition of Ready.

According to Mike Cohn’s recommendations, teams should adhere to two principles to avoid this dysfunction:

Avoid mandating 100% compliance with any criteria. Regard the criteria as guidelines, not strict rules.

We should aim to guarantee that we’re not unintentionally implementing a phased-gate approach and reverting to waterfall methods. Halting work at specific stages and passing it along in batches hinders flow.

The Agile for Humans Podcast shares a similar perspective, suggesting that the objective is to understand the work to a sufficient degree that we believe it’s responsible to start.

I consider this crucial. I’ve witnessed teams refrain from including a story in a Sprint simply because they needed clarification on the color of a button. Unless there’s an extraordinarily unique aspect to your situation, altering the color of a button won’t entail a significantly different effort, regardless of the chosen shade. Moreover, it’s improbable that we would need more time than what would be available in a Sprint to decide on the button color. Even if there were delays in the design process, opting for any reasonable color to deploy the functionality and gather feedback should still be achievable within a Sprint.

Bloated DoR

Avoid overloading your checklist. If we include every detail, the list becomes just as burdensome as the work itself. Concentrate on the items that are relevant in most cases or those rare, critical issues that we must avert at all costs.

Initially, trying to preempt all potential mishaps may seem logical to increase the odds of a successful Sprint. However, bloating the Definition of Ready (DoR) will lead to inefficiency. We won’t be able to swiftly employ this tool in discussions to ensure we’ve addressed all necessary points.

Over-Reliance on the Checklist

Avoid assuming that our pre-established criteria eliminate the need for critical thinking. The earlier version of ourselves that set the parameters we’re assessing could not have anticipated every conceivable scenario or question that might arise. The Definition of Ready (DoR) is a guideline, not an absolute solution.

In the TV series Doc Martin, Mrs. Tishell begins wearing a neck brace as a psychosomatic crutch. However, by the time the doctor persuades her to remove it, she has worn it for so long that it has resulted in real damage, making the brace now medically necessary.

Mastering the art of navigating ambiguity is one of the most challenging skills for teams to develop, yet it’s also incredibly valuable. Avoid relying on the Definition of Ready (DoR) as a crutch, as it may ultimately hinder your ability to navigate uncertain situations.

Excluding the Team

I’ve observed instances where leadership or a highly driven team member has assumed the responsibility of crafting the Definition of Done and subsequently presented it to the team as a mandate for enforcement.

They intended their decision to alleviate the strain on others’ capacity for alternative tasks, not to exclude or sideline team members from the process.

“Those convinced against their will are of the same opinion still.”

- Dale Carnegie

Yet, this approach nearly always leads to a deficiency in team ownership and overlooked perspectives in the Definition of Ready (DoR). Other team members may have been able to collaboratively establish more comprehensive criteria for evaluation. Furthermore, fully embracing a process imposed upon you poses a challenge. In contrast, it’s much easier to support something that you comprehend the value of and have actively contributed to shaping.

Belated Application

Depending on your specific agile approach, your work intake process may involve a formal planning event or a just-in-time workflow where work begins as other tasks conclude. While this point in your process might seem like an opportune moment to check for readiness, it could lead to uncovering issues too late. Ideally, it’s best to refine the Product Backlog Items (PBIs) at the top of your backlog a bit before your work intake process. This proactiveness ensures that items near the forefront of the backlog are ready to be started when their turn comes up.

Discovering something that prevents work from commencing right when you’re ready to pull in more tasks is too late.

Consider the conventional pre-flight checklist used by airports. They don’t wait until passengers are on the plane to check if it needs refueling. To meet their scheduled flight times, they attempt to complete as much as possible in advance.

Who Defines the Definition of Ready

The Definition of Ready (DoR) is typically defined collaboratively by the Agile development team. This collaboration includes members such as developers, Product Owners, Scrum Masters, and any other relevant stakeholders.

The goal is to establish a shared understanding of a work item’s criteria before it is considered ready for implementation.

In the grand scheme, the developers must assess whether a Product Backlog Item is ready for selection in a Sprint. We task the developers with executing the work. If they need a clearer understanding of the task at hand, it may not be prudent to start, depending on the level of ambiguity or potential obstacles.

Although the ultimate decision rests with the Developers, the Product Owner is highly motivated to confirm that user stories are well-defined in advance. They aim to optimize the value delivered by the team, and one way to accomplish this is by ensuring that valuable tasks don’t get stuck in the pipeline.

Definition of Ready Transparency

Every agile team operates with an implicit Definition of Ready, whether they’ve formally articulated it or not. When developers choose a task, there’s an underlying process to assess its readiness for execution.

For Scrum Teams, this could manifest as refraining from selecting a PBI during Sprint Planning because they believe they can’t resolve the issue within the Sprint. On the other hand, for Kanban or flow-based teams, it might involve initiating the next item, encountering a roadblock, and then organizing meetings or sending emails to attempt to resolve the issue.

Teams that adopt a formal Definition of Ready are naming and explicitly defining this process and sharing it with others. Even if these steps are seamlessly integrated into your existing process, documenting them openly is more likely to yield positive outcomes than negative ones. Sharing these criteria with others heightens the likelihood that a Product Backlog Item will be ready when it reaches the development team.

However, it’s important to be cautious about solving a problem that doesn’t exist. If every PBI consistently arrives at your team well-refined, or if they can swiftly address the remaining questions and rarely need to skip valuable work due to ambiguity, the return on investment for explicitly defining the DoR might not warrant the effort of creating and maintaining the artifact.

Definition of Ready Example

Your Definition of Ready should be tailored to your unique situation and aim to address typical challenges proactively. Some proven criteria have worked well for other teams and thus offer valuable context for crafting your own.

• Exemplified: Clear examples of mock-ups, expected vs. actual behavior, or other supporting documentation are provided.
• Shared Understanding: All known questions have been addressed, ensuring a collective grasp of the task.
• Clear and Testable: Ambiguity is minimized, and acceptance criteria are present, making the task both clear and easily testable.
• Supportable: Performance criteria (if applicable) are outlined, ensuring the task can be effectively supported post-implementation.
• Estimated and Right-sized: The team is aligned on the work needed to complete the task, ensuring it is appropriately sized for a single Sprint.
• Independent: External dependencies have been resolved, allowing the task to be tackled independently.
• ROI-Conscious: The task offers a reasonable cost-to-value ratio, ensuring the effort invested yields substantial returns.

Some common criteria overlap established best practices outlined by INVEST and the 3Cs of User Stories. In fact, some teams incorporate these acronyms directly into their Definition of Ready (DoR).

How To Create a Definition of Ready

1. Get buy-in from the team

The entire team should unanimously recognize the importance of a DoR or, at the very least, be open to experimenting to assess its potential value.

2. Gather some example criteria

Critiquing an existing item is invariably simpler than starting anew. Providing sample criteria, like the example above, offers the team a starting point and contextualizes their expectations for what they might want to include in their DoR.

3. Schedule a workshop that includes the entire team (including the Product Owner)

I suggest dedicating at least one hour to this task. Collaborative input is crucial, and convening everyone for a focused session is the most efficient way to kickstart the process and swiftly generate an initial draft.

4. Establish the value and purpose of the DoR

Begin by establishing a shared understanding. Define the objectives and the anticipated value of this endeavor. Identify the triggering event that prompted the team to consider this working agreement—perhaps a problematic sprint or a challenging sprint planning session. Perhaps backlog refinement sessions have highlighted stakeholder unpreparedness. Communicate the expected improvements from implementing a DoR, framing it as a hypothesis to align everyone’s focus and mindset.

5. Brainstorm additional criteria

Now that you’ve established the vision and you have examples from other teams, it’s time for your team to brainstorm (or pinpoint specific examples they want to adopt) practices that they believe will improve their current situation.

6. Pick the final criteria that you want on your checklist

After the brainstorming session, assess the group of items to determine what makes the final cut. Eliminate any redundant entries and ensure that the final list remains manageable.

7. Decide How to Document

Maintaining transparency by sharing the list with those crafting PBIs is crucial. What’s the most logical method for achieving this in your specific context? Identify the responsible party who can prepare the documentation.

8. Clarify Criteria to reach a shared understanding

Go through each item with the ultimate format of your artifact in mind. Ensure that each statement is clear, concise, and easily understandable by individuals absent from the workshop.

9. Publish in a transparent location

Make sure to publish the document where all stakeholders can access it and communicate its existence to ensure everyone is informed. Consider meeting to briefly discuss its purpose and creation and emphasize that it’s a dynamic, evolving document.

10. Review and Refine

The DoR is not a fixed or universal checklist but a team-specific agreement that evolves as the team learns and improves. Regularly review the artifact to verify its continued relevance and usefulness. As you encounter future refinement-related issues, consider updating the DoR proactively to address them in advance.

What the Definition of Ready and Definition of Done Have in Common

The Definition of Done and Definition of Ready are often mentioned in tandem, yet they are distinct, each serving its own purpose.

Both the Definition of Done (DoD) and the Definition of Ready (DoR) serve as working agreements within a team, offering a set of collectively established guidelines and expectations. Typically presented as concise checklists, they facilitate smooth workflow transitions. These tools enhance development process quality, transparency, and efficiency. They are adaptable, evolving in response to the team’s changing needs and circumstances.

The key distinction lies in their purpose and emphasis. The Definition of Done (DoD) sets forth criteria for a team to deem a work item completed. On the other hand, the Definition of Ready (DoR) concentrates on prerequisites necessary to initiate development with a reasonable assurance of unimpeded progress towards completion.

Definition of Ready in Agile

Some Agile practitioners and teams strongly advocate using a DoR because it provides a clear set of criteria that user stories or tasks must meet before they are considered ready for implementation. This clarity can lead to more efficient development processes and reduce the likelihood of encountering unexpected issues later in the Sprint.

On the other hand, there are also Agile practitioners who may be more cautious about implementing a DoR. They might argue that, in some cases, an overly rigid or extensive DoR could lead to excessive upfront planning or analysis, which may not align with Agile principles of flexibility and responsiveness to change.

It’s important to note that neither perspective is inherently right or wrong. The effectiveness of a DoR can depend on factors such as the team’s specific workflow, the nature of their projects, and their level of experience and expertise.

Ultimately, the team should base the decision to use a DoR on their unique needs and circumstances, and it’s advisable to regularly evaluate its impact to ensure it continues to provide value.

Definition of Ready in Scrum

The Definition of Ready sets clear criteria for a backlog item before the team can include it in the current Sprint. It ensures Product Backlog Items are well-defined, reducing ambiguity. However, contrary to popular belief, the DoR is not a core component of the Scrum framework.

Definition of Ready Scrum Guide

The closest the Scrum Guide gets to calling out the Definition of Ready is in this passage:

“Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.”

- Scrum Guide

This phrasing has evolved slightly across the seven versions of the Scrum Guide. However, it’s worth noting that the Scrum Guide has never mentioned a specific artifact referred to as the ‘Definition of Ready’ in any version, up to and including the 2020 release of the Scrum Guide.

Is Definition of Ready Mandatory in Scrum

The Definition of Ready is not mandatory in Scrum. Given that the DoR isn’t even mentioned in the Scrum Guide, one would be hard-pressed to argue otherwise.

Is Definition of Ready Part of Scrum

While the Definition of Ready isn’t explicitly outlined in the Scrum Guide and isn’t obligatory within the Scrum Framework, it’s important to remember that the framework is just that—a framework. It allows room for teams to define their own implementation. If your team finds value in the DoR and can avoid its pitfalls, they can seamlessly integrate it within Scrum.

Definition of Ready Scaled Agile

SAFe doesn’t formally prescribe the Definition of Ready (DoR). Still, it’s a valuable practice that some SAFe teams adopt to ensure their backlog items are well-prepared for implementation.

Since SAFe’s team-level practices closely align with Scrum, the team can incorporate a DoR if it benefits their workflow. It neither contradicts nor is obligatory within SAFe, provided you steer clear of its potential pitfalls.

Notably, the SAFe website and glossary do not make any explicit mention of the Definition of Ready.

Definition of Ready Variations

Some teams adopt specific Definitions of Ready at various levels of their hierarchy or for specific backlog item types. I’ll cover some of those here for the sake of completeness.

Definition of Ready Epic

A Definition of Ready (DoR) may exist at the epic level to guarantee a thorough evaluation of ideas before assigning them to teams. It’s worth noting that while these guidelines align with team-level practices, they may vary in specific criteria.

Epics represent significant features or initiatives that teams often divide into smaller, manageable user stories. Teams commonly adopt a portfolio-level perspective, organizing work into epics. This program level will frequently have its process to facilitate the flow of epics through the pipeline.

As epics you evaluate epics, the application of a Definition of Ready may be beneficial in confirming the idea is worth implementing. Some criteria for this level might be that the epic has:

• An associated hypothesis specifying the outcomes we hope to achieve.

• Defined metrics will allow us to measure if we’ve achieved the desired outcome.

• Alignment with our strategic vision.

• ROI justification (is the juice worth the squeeze).

Definition of Ready for a Bug

Bug fixes often follow a distinct Definition of Ready (DoR) compared to user stories due to their unique development process. Key criteria involve providing details to assist the developer in pinpointing the root cause. These details include outlining expected behavior, detailing actual behavior, and providing clear reproduction steps, all of which are crucial for effective issue resolution.

Definition of Ready for a Release

While releases typically have their own Definition of Done, experts don’t commonly emphasize a Definition of Ready for a release. This lack of recommendation is likely because fewer barriers exist to initiating a release. It’s worth noting that the term ’definition of release ready’ pertains to a Definition of Done at the release level, despite its name.

Works Consulted

• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
• Scrum Guide
• Agile Manifesto
• Agile for Humans with Ryan Ripley and Todd Miller: Rethinking the Definition of Ready in Scrum and Kanban
• Definition of Ready: What It Is and Why Its Dangerous
• The Definition of Ready in Scrum
• How to Manage Defects Effectively (Without Moving Cards Backward on Your Board)
• Why Scrum Teams Fail to Meet Their Sprint Goals
• Leading Agile: Definition of Ready

TLDR

The Definition of Ready (DoR) is like a pre-flight checklist for agile teams. Just as a pilot ensures their plane is ready for takeoff, teams use the DoR to confirm their user stories are prepared for development. It sets clear criteria, avoiding ambiguity and potential pitfalls. However, timing is crucial. Like a checklist that’s too early or too late, applying the DoR at the right moment ensures smooth progress. Refinement is key, but overdoing it leads to waste. Ultimately, the DoR, like a well-executed pre-flight routine, is about balancing planning with delivering value, ensuring your efforts don’t meet a fiery end.