Definition of Ready and Definition of Done: Lean thinking made actionable.

By James K Smith, linkedin.com/in/jamesksmith, [email protected]

Agile Coaches heavily push Definition of Ready and Definition of Done. Let's review what these two notions mean:

Definition of Ready

Once an agile unit of work (a story) meets the Definition of Ready, it means the story is ready to be pulled into a sprint. Agile coaches teach basic requirements for a story to meet this definition. Most common is the INVEST criteria.

I – Immediately actionable, meaning the story has no external dependencies.

N – Negotiable, meaning at some point in the story's refinement, it may have had to be pivoted a bit to become a deliverable with acceptable business value. The business partner, PO's and teams contribute to this negotiation.

V – Valuable. Remember, agile-based processes are derived from human survival processes. Working on something that isn't valuable is a survival anti-pattern.

E – Estimable, meaning if teams can't relative size estimate the complexity of a work item, then they don't have enough information to even consider working on it. Exceptions are defects and Kaizen stories which can be pulled into a sprint, but are not pointed.

S – Sized correctly. If a story doesn't meet a size that a team can feel confident committing to in a sprint, or if the story is just too small to merit team attention, then that story can't be pulled into a sprint. My recommendation for most teams is to accept stories no smaller than a 3 (not worth the administration) and no larger than a 13 (too many eggs in one basket if larger) if those teams are using the Fibonacci sequence for sizing.

T – Testable. Business value of a completed story must be validated through testing. If that's not possible, then the story should not be worked on. Exceptions would be defects and Kaizen stories, which are not pointable. By the way, a major contributor to the success of a scrum team is the PO driving Acceptance Test Driven Development (ATDD). PO's should work closely with stakeholders and the team to create at least one Acceptance Test for each Acceptance Criterion. See my Scrum vs Kanban Followup for more details.

What about research spikes? Honestly, I hate these kinds of stories. They are an excuse for poor refinement and low-quality results. And it's incorrect to point these stories since they have no business value, and are not a defect or a Kaizen (improvement story). In part 2 of my Cone of Uncertainty installment, I'll show you how to eliminate pulling research spike stories into sprints all together.

So that's the INVEST criteria and basic starting point for your Definition of Ready. To be sure, a team may have additional requirements such as test data and wireframes as needed to for a story to be pulled into a sprint.

What's important about the Definition of Ready is that it helps teams commit to getting work done. Whether a sprint backlog is comprised of one story or ten, the Definition of Ready is the team's agreement that the stories can be completed in a single sprint. That's the team's promise to the stakeholders. And the stakeholders expect the team to meet that promise.

Just as importantly though, is when the team tells their PO that a story meets the Definition of Ready, the PO can stop work on that story and move onto the next. There's a formal way to do this, but this is a question that the PO should always be asking the team. “Is this story ready to be pulled into a sprint?” If it is, then PO's don't do another thing to that story. They don't even think about the story, and reallocate their bandwidth to other stories. Why? I expect PO's I train to be working on their backlog responsibilities full-time, eventually getting their backlogs to meet the Rule of 3's – 3 sprints worth of stories meeting the Definition of Ready, and 3 months worth of estimated stories, all representing a backlog that has 3 quarters of a year of stories out into the horizon.

Wow, that seems like a lot of trouble doesn't it. Well there's a reason for the Rule of 3's. When the teams I train embrace and really begin to showcase agile values (trust, transparency, commitment, and continuous improvement), I expect them to eventually improve their velocity 400% over their initial velocity. That means they are going to be emptying the PO's backlog at a very fast rate, and it's incumbent on the PO to maintain that backlog so that a high-performing team can continue working.

So that's what the Definition of Ready means in action. A team's confidence that they can commit to getting their stories done during a sprint, but also that DoR means a PO can stop working on a story and begin refining the next.

Definition of Done

The great thing about the Definition of Done, is that it's the PO's validation of the team's Definition of Ready. The Definition of Done is a great contributor to reinforcing (or diminishing) agile values.

Agile coaches teach basics for Definition of Done as well. For instance, all acceptance tests must pass for a story to be accepted. If just one test fails and the sprint is otherwise done, that story doesn't meet DoD and cannot contribute to the team's velocity. Other requirements might be added, such as a story should meet 80% unit test code coverage. But the most valuable aspect of the Definition of Done is that the team has validated their judgment that the story met the Definition of Ready in the first place. This is substantial, because the result is that PO's don't have to worry about the quality of a releasable increment resulting from a sprint. Additional work for testing is minimized in the spirit of improving the process.

A low performing team who fails a lot of stories on a regular basis shouldn't be doing scrum at all and probably should be doing kanban because theres nothing to show that the team's Definition of Ready and Definition of Done are of any value to the process. The team is just working a todo list.

But when the Definition of Ready and Definition of Done begin validating each other, that's the mark of a high-performing scrum team.

So coaches, when you begin working with a team, take a close look at that team's Definition of Ready and Definition of Done, how they validate each other, and how they contribute to a lean, repeatable, and therefore measurable process.

Until next time,

James

James Smith has a 25 year career building high-performing technology teams and organizations for a multitude of industries. He enjoys working with startups to some of the largest corporations in the world, has held several highland games world records, and has pitched to VC using nothing more than napkin drawings and a bowl of M and M's. He claims there's only one truely always-optimizable XOR result in the universe, that either 2+2=4 or it doesn't, but not both. Otherwise, some of the best answers can be found in the grey areas.

#kanban #agile #scrum #safe #less #velocity #flowefficiency #cycletime #agiletransformation #agilecoaching #lean #pmofficers #highperformingteams