In Scrum and any other framework based on Agile approach, we need a clear and mutually agreed definition on what constitutes a Ready scope item to go into the development cycle and what criteria needs to be met to consider it Done.
The Short Version would be:
“Ready” refers to the state of adequacy of the requirements (for development & testing) as provided in the high priority stories in the Product Backlog that Product Owner would like to present to the Development Team during the Sprint Planning.
“Done” refers to the state of Release-Readiness (i.e. completeness of the Development, Testing and the other Acceptance Criteria) as achieved on Sprint Backlog Stories at the end of the Sprint.
Now let’s take a more detailed look:
Product Owner (or as we call it “PO“) owns the Product Backlog and the Release. That puts PO on both sides of the Sprint.
PO presents the top few items on the Product Backlog to the Development Team during the Sprint Planning, and the Development Team reviews, discusses, negotiates and commits to what they can deliver during the new Sprint and bring them into their Sprint Backlog.
PO is the ultimate authority to accept or reject the product (increment) that is completed – and ready for Release if PO decides – at the end of the Sprint.
During the Sprint Planning, the Development Team goes through the Stories that PO is presenting and reviews the required work with the PO and decides / negotiates on their selection for the new Sprint.
Development Team owns the Sprint Backlog and is accountable for delivery of the selected Stories – as per the required quality.
As a result, they can only commit to Stories that have enough requirement details – i.e. are “Ready” to get picked for the new Sprint – to allow for a clear understanding of what needs to be done to develop and test the work.
Ready means a clearly defined Story with a
- Clear set of Development Requirement
- Clear Statement on the Business Value that will be resulted from the implementation of this Story (or the Product Increment this Story belongs to).
- Clear listing of Pre-Dev enablers that need to be added to the Story prior to Dev work (such as UXD wireframes, Visualization Designs, Prototypes, Mock shots, Simulation Data, Test Data and so on).
Ready also requires the Story to meet the following criteria:
- Its rough estimate (sizing) should show it would fit within one Sprint. (The actual final sizing will be done by the Development Team).
- It should avoid any pending dependencies to any external resources or elements during the Sprint (i.e. The Development Team should not have to depend to someone outside their team to deliver any piece before they can take on the Story).
- In cases where it is inevitable that a live external dependency is going to exist and follow a Story through the Sprint, proper adequate coordination with the external dependency must be arranged and closely tracked to avoid disruption to the work during the Sprint (let’s not forget that we need to consider time needed for testing once the Dev is completed and a delay imposed by external dependencies can damage our commitment to deliver!)
Development Team decides if a Story is Ready for selection into the new Sprint.
If they decide a Story presented by the PO is Not Ready, they can ask PO to provide the needed clarification and details (and/or examples, mock images or prototypes).
Development Team should NEVER be forced to bring in Stories that they did not commit to deliver.
Backlog Refinement sessions, even though they are not officially part of Scrum process, have empirically proven to be the best opportunity for both parties to review the Readiness of the Stories and to ask for clarifications.
PO would then have time to continue to find answers to Development Teams’ questions on the requirements and clarifications.
Definition of Done (DoD) is a mutual agreement between the Development Team and PO on what constitutes a Story that is ready for Release.
Some organizations have pre-defined DoDs for a variety of Story types. They may even be defined at departmental levels.
In other cases no such pre-definition is in place and it is up to the Scrum Team to establish that agreement.
It is important for all Scrum Teams working within the same department or being in any sort or interdependent working relationship to establish and use the same DoD.
DoD can be defined as a blanket cover for all Story types, or can be more granular to provide a different set for any specified Story types.
DONE is a qualifying status for a Release Ready Product Increment.
Based on what it means for that Scrum Team (or their department) to be considered Release Ready, it should contain cover:
- Completion of Development
- Completion of Code Review
- Completion of Testing: Unit Testing, Regression Testing, Integration Testing, Functional Testing, Non-functional Testing, User Acceptance Testing, Usability Testing, Stability Testing, Stress Testing …
- Any other QA work needed
And meeting all Acceptance Criteria (for that specific Story or group of Stories)
- SLA (Service Level Agreements),
- Performance (meeting certain metrics)
- Compliance (adhering to certain constraints or coverage)
- Information Security Audit (if needed)
- Accessibility Audit (if needed)
- Technical Debt (either to lessen or at least not add to)
- PO Accepted the Product Increment (and deemed as Releasable)
- Stakeholders Sign-off (or Acceptance of any kind): would includes: Demo is prepared, Demo is presented, Approval Received
- Knowledge Center updated (or manuals or training materials and such)
Also, depending on the Release, we may need to also have a few more items on our list before the Sprint is considered as Done (i.e. Sprint Goals are all check marked):
- Build is complete and its free from bugs.
- Build is successfully promoted to the Production Environment.
- Release Notes are prepared and provided
- Infrastructure Change Documents provided
- Operations hand-over is completed and they are ready to take over after the Release. (This may also need to extend to other areas as well, such as Call Center or Customer Support).
Note that “Readiness” and “DoD” are Not Static and can Change as Needed Through Time!
The organization’s Agile Center of Excellence should be tasked with these definitions and their updates. It should also have an oversight on their proper implementation.
Depending on your Scrum Teams’ maturity level, you may want to introduce these two key subjects to them in an evolutionary change to first ensure they are receiving properly detailed Stories (following the “Just Enough” model), while making sure the Dev and Test is completed before any item is marked as Done.
Other checkpoints on your teams’ acceptance criteria can be incrementally added to their process as they show strength and capability to adhere to the key checkpoints.
Remember that improvement should be implemented gradually (as an evolutionary change) so it won’t disrupt team’s delivery while incrementally improve the process for them.
Cheers!
Arman Kamran (The Agilitizer)
