Scaling Scrum - DoD - DoR - Scrum Framework

Scaling Scrum allows teams and organizations to excel iteratively and incrementally deliver valuable products of “Done” working releasable software within a Sprint. Key focus areas are Definition of Done, Definition of Ready & Scaling Scrum.

Scaling Scrum – Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a list of requirements that a user story must adhere to for the team to call it complete. The same definition guides the Developers in knowing how many Product Backlog items it can select during Sprint Planning.

Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. Product Backlog item which does not meet the Definition of Done, cannot be released or even presented at the Sprint Review. Instead, those will return to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriately for the product. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

The goals of DoD

Build a common understanding within the Team about Quality, Completeness & limits the cost of rework once a feature has been accepted as “done”. e.g. Security, performance requirements are added to the Definition of Done so that developers can satisfy those in each increment.
Use as a checklist that User Stories (or PBIs) are checked against & which usefully guides pre-implementation activities: discussion, estimation, design.
Ensure the increment shipped at the end of the Sprint has high quality and that the quality is well understood by all involved.

Acceptance Criteria of a User Story consist of a set of Test Scenarios that are to be met to confirm that the software is working as expected. The difference between these two is that the DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story. But both DoD and Acceptance Criteria must be met in order to complete the User Story.

DoD Examples: Code peer-reviewed? Unit tests passed? Functional tests passed? User Acceptance tests passed? Etc

Acceptance Criteria Examples: A user cannot submit a form without completing all the mandatory fields, Payment can be made via credit card, etc.

Scaling Scrum – Definition of Ready

Definition of Ready is a set of agreements that let you know when a user story is really done, the team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration. Few benefits are

Measure a backlog item’s “ready” state.
Help the team identify when the product owner or another team member becomes overwhelmed.
Keep the team accountable to each other.
Reduce pressure on the team to commit to estimates before stories are “Ready”.
Reduce “requirements churn” in development.
Definition of Ready helps in minimizing the Rework on a user story.

A “ready” backlog item needs to be clear, feasible, and testable:

A user story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity.
An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested.
A user story is feasible if it can be completed in one sprint, according to the Definition of Done. If this is not achievable, it needs to be broken down further.

DoR for a user story

The story is well-written & defined; and has a minimum of 5 acceptance tests defined.
The story has been sized to fit the teams’ velocity & sprint length: 1-13 points.
The team has vetted the story in several grooming sessions—its scope & nature is well understood.
If required, the story had a research-spike to explore (and refine) its architecture and design implications.
The team understands how to approach the testing of the stories’ functional and non-functional aspects like performance criteria.
Any dependencies to other stories and/or teams have been “connected” so that the story is synchronized and deliverable.
The story aligns with the sprints’ goal and is demonstrable.

DoR for a sprint

Prioritized sprint backlog.
Defects, user stories and other work the team has committed to are contained in the sprint backlog.
No hidden work.
All team members have calculated their individual capacity for the sprint.
Full-time on project = X hours per day.
All User Stories meet Definition of Ready.

Sample Definition of Ready (DoR)

PO and Dev Team need to have talked about the story at least once.
User Story is clear.
User Story is testable.
User Story is feasible.
User Story defined.
User Story Acceptance Criteria defined.
User Story dependencies identified.
The story must be broken down enough to fit in a single sprint.
User Story sized by Development Team.
Scrum Team accepts User Experience artifacts.
Performance criteria identified, where appropriate.
Scalability criteria identified, where appropriate.
Security criteria identified, where appropriate.
A person who will accept the User Story is identified.
Team has a good idea of what it will mean to Demo the User Story.

Scaling Scrum – Nexus Framework

Scrum is a simple framework for delivering software products using an empirical approach in which teams deliver value in small increments, inspect the results, and adapt their approach as needed based on feedback. It consists of a small set of events, roles, and artifacts, bound together by practices, and enlivened by values that are the key to making it work.

Nexus extends Scrum to guide multiple Scrum Teams on how they work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.

Scaled Professional Scrum is based on the unit of development called a Nexus. The Nexus consists of up to 10 Scrum teams, the number depending on how well the code and design are structured, the domains understood, and the people organized. The Nexus consists of practices, roles, events, and artifacts that bind and weave the work together to produce a whole.

LeSS (Large-Scale Scrum)

LeSS is a framework for scaling agile development to multiple teams. The framework scales up with minimal additional process compared to single-team Scrum. i.e. use the as little process as possible to get multiple Scrum teams to work well.

For Example:

LeSS recommends that multiple teams have the same Product Owner and a shared Product Backlog.
Their sprints are synchronized to the Product-level Sprint leading to one integrated Potentially Shippable Product Increment.
Sprint Planning, Sprint Review, and Sprint Retrospective run at the same time for all teams.