Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

The Definition of Ready (DoR) defines the criteria a story must meet in order for the delivery team to start working on it. In other words, when the story is ready to be brought into a sprint.

• Definition of Ready defines when a story is ready to enter a sprint
• Definition of Done defines when a story is ready to leave a sprint

What is the Value of a DoR?

If stories are not sufficiently understood at the start of a sprint, the team will be less effective. The team may hurriedly try to push a story to ready state and risk short-cutting discussion, starting development without fully understanding the story, incorrectly estimating the story, or incorrectly implementing the story.

DoR Guidelines

• Definition of Ready criteria...
  • Should apply to all stories and are not specific to a particular user story.
  • Are defined and reviewed by the delivery team and Product Owner prior to the start of a project, e.g. Sprint 0
  • Should not change during a sprint. Changes to a team’s DoR are typically infrequent and are the result of feedback captured in a retrospective.

DoR Sample

Note: This is an example only - specifics will differ by team and project. Always define what makes sense for your current project.

Getting User Stories to a “Ready” State

Backlog grooming meetings are an opportunity to ensure that the user stories for upcoming sprints meet the DoR criteria. During grooming the team will discuss, provide clarity, and prepare stories for a sprint prior to sprint planning. The team and Product Owner discuss the top items on the product backlog, add details, break large stories into smaller ones, etc. By doing so earlier, all parties are given a chance to research questions they may not be prepared to answer immediately.

It is not necessary for all stories to meet the DoR at the start of a project. Teams will work over the course of the project to add the right amount of detail at the right time. As a story rises in priority and nears the top of the product backlog, more detail should be provided. Delay detailed requirements collection until the last responsible moment.

After User Stories are at “Ready” State

When a story meets the “Definition of Ready” state, we recommend doing these activities before active development starts:

1. Create Design Documents to outline your design approach and identify the objects you will be editing or adding to the application. Keeping detailed documentation of development is important to keep your team aligned on design and have something to refer back to if necessary.
2. Draft test cases before development. Designing your story with your test cases in mind will allow the developer to consider edge cases before even starting to build. Having test cases ahead of time gives the developer more of an idea of the requirements they need to uphold.

See Also

• Using a Definition of Ready
• The Definition of Ready in Scrum
• New to agile? INVEST in good user stories - Agile For All
• Building "Definition of Done" and "Acceptance Criteria" lists in JIRA

Definition of Done

The goal of a sprint is to deliver potentially shippable product at the end of each sprint. A Definition of Done (DoD) defines what a potentially shippable product is, what it includes, and what steps were done to get there. It answers the question "When is this story done?".

• Definition of Ready defines when a story is ready to enter a sprint
• Definition of Done defines when a story is ready to leave a sprint

What is the Value of a DoD?

One of the goals of agile is to "deliver working software frequently". In order to have good working software, you need to define when the work is considered done.

• "Almost done"...
  • Doesn’t provide the desired value to the user.
  • Often is not almost done; remaining work can be misunderstood and pile up at the end of a project.
  • Needs to be picked up again. Switching back and forth on tasks is inefficient – "multitasking is deceptively time-intensive"

DoD Guidelines

• The Definition of Done…
  • Defines the general standards and requirements of “Done” for any piece of work the team does.
  • Should apply to all stories and is not specific to a particular user story.
    • Some details may be component-specific; for example, user interfaces may require UXD signoff and other stories may not.
    • In contrast, acceptance criteria apply to only one user story and list the specific functional criteria that must be met for a particular story to be complete.
  • Covers anything necessary to fully complete a story. This may include development, testing, sign-off, configuration, installation, documentation, and knowledge transfer materials
  • Should incorporate testing standards such as unit testing, peer reviewing, regression testing, exploratory testing, SIT, and UAT completed by the team to complete a story. Optionally, the team may include Automated or Performance testing before they conclude a sprint depending on the project.
  • Is defined and reviewed by the delivery team and Product Owner prior to the start of a project, e.g. Sprint 0
  • Should not change during a sprint. Changes to a team’s DoD are typically infrequent and are the result of feedback captured in a retrospective.

DoD Sample

Note: This is an example only - specifics will differ by team and project. Always define what makes sense for your current project.

Exceptions

• Potentially shippable does not always mean shippable. Some activities require shared teams or equipment and may not be feasible in every sprint. This could include load testing, final documentation, security scans, or full regression tests. To account for these activities, teams sometimes utilize a hardening sprint, which is extra time before a release for release-specific activities. In order to be used effectively, hardening sprints should:

  • Not be a dumping ground for unfinished work or “one more feature”. Stories should be completed in their respective sprints, not finished in the final sprint. New stories should not be added.
  • Contain only a fixed predefined set of tasks which are needed for release but are not feasible in each development sprint.
    • Define any hardening sprint tasks in Sprint 0, at the same time as DoD is established. If a task is needed for release, it should be in the DoD or the hardening sprint specification.
    • Possible considerations for a hardening sprint:
      • Client UAT testing
      • Other testing not feasible in the development sprints which may include: full application regression tests, security scans, full load/performance tests, etc
      • Finalization of release materials
      • Handoff/delivery meetings
    • Any application changes in a hardening sprint should be approached with strong caution, since they may bypass some of the release-readiness activities, and the time available for last-minute defect fixes is minimal. Changes should be transparently managed, with the opportunity to understand the impact of addressing issues versus the risks involved.
  • Only contain what must be put at the end and is safe to put at the end
    • For example, full-load testing may require dedicated equipment, but much smaller performance testing can be done in sprints by working with non-trivial databases, some multi-user testing, etc.

  Always look to move tasks out of a hardening sprint and into the development sprints.

  See Also

  • Definition of Done: A Reference
  • When is a User Story "Done?"— Acceptance Criteria and the Definition of “Done”
  • Correct Use of a Release Sprint