“Scrum begins with Done” says Gunther Verheyen. Elsewhere he adds:

“If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint.”

Scrum is a simple framework for complex product delivery. Software development is by nature complex; conceiving, specifying, designing, programming, documenting, testing and bug fixing what is essentially an algorithm informed by people — often used in complicated situations.

Plus there’s always a regular dose of unknown unknowns — changes in external and internal requirements. And, of course, budget constraints. So the simple framework of Scrum really helps us manage a complex problem.

A software product should have two key aspects:
1 — features that are useful to users
2 — features that are usable (actually work)

We could say this another way:
1 — building useful features means we are building the right thing
2 — building usable features means we are building them the right way

‍

Employing aspects of the Scrum framework allows us to say:
1 — to help us build the right thing, we use a Definition of Ready
2 — to help us build the right way, we use a Definition of Done

Definition of Ready (DoR)

The DoR is a checklist of activities. They guide the product owner and stakeholders in creating user stories to help the delivery team understand the right thing to be build.

The main purpose in following the DoR guide is to prevent problems before they have a chance to start. To avoid beginning work on features that don’t have clearly defined completion criteria — which usually translates into costly back-and-forth discussion or rework.

When the work is set for the team it’s declared “Ready”.

‍

‍

‍

‍

‍

‍

‍

‍

Definition of Done (DoD)

Done has become a key concept in Scrum. It defines the quality expectations that a piece of software must exhibit to make it releasable. “Scrum begins with Done” means that we know, before we start, what something needs to be prior to being released to users.

‍

A DoD is a checklist of valuable activities required to produce software. Importantly, it’s non-static and influenced by reality (i.e. it changes to reflect the work required and is also realistic).

‍

‍

‍

‍

‍

‍

‍

‍

A DoD provides transparency of quality between the product owner, development team and stakeholders. It’s the definition of what’s required for something to be fit-for-purpose and it helps minimise waste by avoiding rework.

For a piece of work to be declared “Done”, it must meet the criteria listed in the DoD. This may include activities like:

• acceptance criteria met
• unit tests written and passing
• documentation updated
• tested on specified browsers/devices

The DoD is not a comprehensive list of technical best practices, but rather a list of the minimum work generally required to get a product increment to “Done”. Of course we do all the best practices too!

Summary

At EndGame we use the Definition of Ready and Definition of Done to ensure that we’re building the right thing, the right way — to ensure the software we create for you is useful and usable.

‍