What is the Definition of Ready?

In the simplest terms, the Definition of Ready is a checklist that determines whether a User Story is ready to be worked on during a Sprint. It ensures that the User Story is clearly defined and understood by all team members, and that it can be developed and tested within the duration of a single Sprint.

Key Components of the Definition of Ready

Here are some of the key components that make a User Story ready for development:

1. Clearly Defined: The User Story should be defined clearly enough that all members of the team understand what must be done. This includes any required enabling specifications, wireframes, etc.
2. Team-Developed Tasking: If needed, the User Story should include tasks developed by the team. This assumes some ongoing discussion to refine, coordinate, and clarify the tasks.
3. Business Value: The User Story should include a clear statement of the resulting business value. This allows the Product Owner to prioritize the User Story in the Product Backlog.
4. No External Dependencies: The User Story should be free from external dependencies. In other words, there should be nothing beyond the team's control that must be done first in order to complete the story.
5. Estimated and Sized: The User Story should be estimated and sized to complete easily within one Sprint.
6. Meets the INVEST Criteria: The User Story should fully meet the INVEST criteria for user stories, which we will discuss next.

Understanding the INVEST Criteria

The INVEST acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These are the characteristics that make a good User Story:

• Independent: The Product Backlog Item (PBI) should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
• Negotiable: A good PBI should leave room for discussion regarding its optimal implementation.
• Valuable: The value a PBI delivers to stakeholders should be clear.
• Estimable: A PBI must have a size relative to other PBIs. This allows the team to estimate the effort required to complete it.
• Small: PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
• Testable: Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

In conclusion, the Definition of Ready is a vital tool in Agile and Scrum that helps teams ensure they are working on well-defined, valuable, and achievable User Stories. By adhering to the DoR and the INVEST criteria, teams can improve their efficiency, reduce wasted effort, and deliver value to their stakeholders more effectively.

Expanding the Definition of Ready: Writing User Stories and Acceptance Criteria

In the previous section, we discussed the concept of the "Definition of Ready" and the INVEST criteria for user stories in Agile and Scrum. Now, let's delve deeper into how to write a User Story and define Acceptance Criteria using the Gherkin model.

Writing User Stories

A User Story is a simple, concise description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It typically follows a simple template:

    As a [type of user],
    I want [an action]
    so that [a benefit/a value]
    

For example:

    As a customer,
    I want to be able to reset my password,
    so that I can regain access to my account if I forget it.
    

This format helps to keep the focus on the user and their needs, and it encourages the team to consider the value and context of the work.

Acceptance Criteria and the Gherkin Model

Acceptance Criteria define the boundaries of a User Story. They are used to confirm when a story is completed and working as intended. A widely used format for defining Acceptance Criteria is the Gherkin syntax. Gherkin uses a set of special keywords to give structure and meaning to executable specifications. The main keywords are:

• Given: Describes the initial context at the beginning of the scenario, before the action starts.
• When: Describes the event that triggers the scenario.
• Then: Describes the expected outcome or result.

Here's how you might define the Acceptance Criteria for our example User Story using the Gherkin syntax:

    Given I am a registered customer,
    And I have forgotten my password,
    When I request for a password reset,
    Then I should receive a password reset link in my registered email.
    

This Acceptance Criteria clearly defines the context (a registered customer who has forgotten their password), the action (requesting a password reset), and the expected outcome (receiving a password reset link).

Incorporating Value and Feedback into User Stories

In Agile and Scrum, User Stories are not just about defining what needs to be done. They are also about understanding why it needs to be done and how its success will be measured. This is where the concept of value and feedback comes into play. Let's expand our User Story template to incorporate these elements:

    As a ,
    I want ,
    so that ,
    as measured by .

This expanded template ensures that the User Story is not only user-focused and goal-oriented, but also value-driven and measurable.

Understanding Value in User Stories

The value in a User Story is the benefit that the user or the business will gain from the implementation of the feature. It's the answer to the "so that" part of the User Story. By explicitly stating the value, the team can understand the importance of the User Story and prioritize it accordingly.

For example, let's revisit our previous User Story and add a value statement:

    As a customer,
    I want to be able to reset my password,
    so that I can regain access to my account if I forget it,
    as measured by the decrease in customer support calls regarding password issues.
    

Here, the value is that the customer can regain access to their account without needing to contact customer support, which also benefits the business by reducing the volume of support calls.

Incorporating Feedback Processes

The feedback process is how the success of the User Story will be measured. It's the answer to the "as measured by" part of the User Story. By defining a feedback process, the team can understand what success looks like for the User Story and can measure whether or not they have achieved it.

In our example, the feedback process is the decrease in customer support calls regarding password issues. This is a measurable outcome that indicates whether the password reset feature is working as intended and providing the expected value.

Incorporating the Scrum Team's Understanding into the Definition of Ready

In the Scrum framework, as defined in the Scrum Guide, the Scrum Team plays a crucial role in ensuring that a Product Backlog Item (PBI) is ready for a Sprint. The team needs to understand several key aspects of the PBI to ensure it meets the Definition of Ready. These aspects can be summarized in four questions:

1. How will we Develop this?
2. How will we test this to ensure we have the right functionality?
3. How will we Automate the solution to production?
4. How will we Operate This in production, including instrumentation to evaluate the "As Measured By" criteria?

The answers to these questions are bounded by the Definition of Done, which is a shared understanding of what it means for work to be complete, used to assess when a PBI has been fully implemented.

The Scrum Team's Role in the Definition of Ready

The Scrum Team, consisting of the Product Owner, the Scrum Master, and the Developers, is responsible for all product-related activities, including stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

The team is self-managing, meaning they internally decide who does what, when, and how. They are also cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Understanding the Four Questions

Let's delve deeper into the four questions that the Scrum Team```html needs to understand for a PBI to meet the Definition of Ready:

1. How will we Develop this? This question is about understanding the technical aspects of the PBI. The Developers need to have a clear idea of what needs to be done to implement the PBI, including any design, coding, and integration tasks.
2. How will we test this to ensure we have the right functionality? This question is about defining the acceptance criteria for the PBI and planning the necessary testing activities. The team needs to understand how they will verify that the implemented feature meets the desired functionality.
3. How will we Automate the solution to production? This question is about the deployment of the implemented feature. The team needs to plan how they will automate the deployment process to ensure that the feature can be delivered to production efficiently and reliably.
4. How will we Operate This in production, including instrumentation to evaluate the "As Measured By" criteria? This question is about the operation and monitoring of the implemented feature in the production environment. The team needs to understand how they will operate the feature and how they will measure its success based on the defined feedback process.

The Scrum Team's understanding of these four questions is a crucial part of the Definition of Ready. It ensures that the team is well-prepared to start working on a PBI and that they have a clear plan for its development, testing, deployment, and operation. This, in turn, supports the team's ability to deliver valuable, high-quality features that meet the needs of the users and the business.