Ready-to-Done: Streamline User Stories in Appian

Appian Max Team — Tue, 23 Apr 2024 13:19:05 GMT

Current Revision posted to Guide by Appian Max Team on 4/23/2024 1:19:05 PM

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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:

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.
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.

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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Tags: Delivery, project management

Ready-to-Done: Streamline User Stories in Appian

Kim Day — Tue, 31 Oct 2023 16:39:04 GMT

Revision 7 posted to Guide by Kim Day on 10/31/2023 4:39:04 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

Definition of 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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Tags: Delivery, project management

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Wed, 25 Oct 2023 19:28:52 GMT

Revision 6 posted to Guide by joel.larin on 10/25/2023 7:28:52 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

Definition of 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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Wed, 25 Oct 2023 19:26:40 GMT

Revision 5 posted to Guide by joel.larin on 10/25/2023 7:26:40 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

Definition of 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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Wed, 25 Oct 2023 19:26:03 GMT

Revision 4 posted to Guide by joel.larin on 10/25/2023 7:26:03 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

Definition of 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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Wed, 25 Oct 2023 19:22:47 GMT

Revision 3 posted to Guide by joel.larin on 10/25/2023 7:22:47 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

Definition of 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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Wed, 25 Oct 2023 19:20:47 GMT

Revision 2 posted to Guide by joel.larin on 10/25/2023 7:20:47 PM

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?

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

Sample Definition of Ready (DoR) for an Appian Project
User Story prioritized as high by Product Owner
User Story & Acceptance Criteria groomed by team
Acceptance Criteria approved by Product Owner
User Story has been estimated by the delivery team and is no larger than X story points (upper limit defined by team)
No major open questions that could impact the estimate
Additional User Story artifacts approved (if applicable). May include mockups, truth tables, or edge case scenarios
Representative test data received
Web services defined (Sample requests and responses available and operative)
External dependencies resolved

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

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:

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.
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.

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

Sample Definition of Done (DoD) for an Appian Project
Peer Reviewed (Meets coding and UX standards & best practices)
Story meets all Acceptance Criteria and the developer has written test cases addressing all requirements, which have been acceptance tested by developer and independent tester
Story has been thoroughly tested in the Development Environment via unit testing, regression testing, and exploratory testing
Story has no linked bugs
Has been accepted by Product Owner (or UAT)
Expression Rules and other automated test cases passed
Objects added to application package
Database scripts uploaded

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

Ready-to-Done: Streamline User Stories in Appian

joel.larin — Thu, 07 Sep 2023 15:17:40 GMT

Revision 1 posted to Guide by joel.larin on 9/7/2023 3:17:40 PM

sdas

Ready-to-Done: Streamline User Stories in Appian

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done

What is the Value of a DoD?

DoD Guidelines

DoD Sample

Exceptions

See Also

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done

What is the Value of a DoD?

DoD Guidelines

DoD Sample

Exceptions

See Also

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done

What is the Value of a DoD?

DoD Guidelines

DoD Sample

Exceptions

See Also

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done

What is the Value of a DoD?

DoD Guidelines

DoD Sample

Exceptions

See Also

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done

What is the Value of a DoD?

DoD Guidelines

DoD Sample

Exceptions

See Also

Ready-to-Done: Streamline User Stories in Appian

Definition of Ready

What is the Value of a DoR?

DoR Guidelines

DoR Sample

Getting User Stories to a “Ready” State

After User Stories are at “Ready” State

See Also

Definition of Done