Your Agile team probably has a definition of done, and that's a good thing.
On the other hand, a definitions of ready is dangerous and something most teams should avoid.
Hi, I'm Mike Cohn, the author of three best-selling books on Agiles and Scrum.
I help teams succeed with Agil.
And right now I can help you be more successful by convincing you not to use a definitive ready.
A definition of ready acts as entry criteria for the sprint.
Nothing is allowed into the Sprint unless it meets that definition.
To see how this works, let's look at a typical definition for ready.
It might include things like all acceptance criteria have been fully defined.
The product backlog item has been estimated and is five points or smaller, and the user interface has be designed and approved.
Nothing would be allowed into a sprint unless each of those statements is true.
A definition of ready such as this can absolutely help a team avoid problems.
If, for example, a theme has struggled because of bringing big items into its sprints, our rule governing the maximum allowable size of an item is great.
That rule will solve the problem.
But there's a downside, which is that a definition of ready can prevent a team from overlapping work.
Overlapping or concurrent work is a vital component of most Agile approaches.
Testing, for example, should overlap coding.
An Agil team doesn't delay testing until all coding is finished.
To differing degrees, the same could be said of all aspects of software development.
Analysis, design, testing, and coding all overlap.
A definition of ready can hamper a team's agility.
Think about the example I mentioned, which said an item is ready for a sprint only if all its acceptance criteria have been fully defined.
That may sound fine, but it is going to prevent the overlap of work.
The definition of ready is requiring that all acceptance criteria be figured out in advance.
So you can't have some people build the feature at the same time as other people define the acceptance.
Not only is knowing the criteria in advanced sometimes impossible, it's usually unnecessary.
Some acceptance are quite reasonably determined while the team is working on the item.
As another example, recall that the sample definition of ready I shared included that user interface has been designed and approved.
Again, including this in a definition ready will prevent work from overlapping.
This instructs team members that a user-interface design must be done before any other work can begin.
Think of any definition Ready as a gate into the sprint through which work must pass.
Only certain types of work pass through this readiness gate.
It makes sense to picture your definition of ready as a gate, because the whole idea really is nothing more than a step back toward a waterfall or stage
gate process.
So is a definition ready always a bad idea?
No, it's not.
You may want to consider a definitions of Ready to call out dependencies on other teams, especially if those teams frequently fail to deliver to you when
they say they will.
Suppose your team is dependent on something my team's building.
We promised to give it to you by Tuesday.
But Tuesday comes and goes, and my teams gives you nothing.
Wednesday comes, Thursday, Friday, a week goes by.
My team finally gives what we promised, but way too late for you to use it and finish whatever you committed to in the current sprint.
If my team does this too often, you may want to have a definition ready that says you won't bring anything into your sprint that is still waiting on something
from my Team.
If My Team owes you something to do your work, You want it in hand before the sprint starts because of how often MyTeam has jammed you up.
Note that this is absolutely an example of how a definition of ready prevents overlapping work.
It's less agile than if we could overlap work, but in this example, my team has let you down so often, you'll put in place a definitions of Ready to stop
it from happening again.
While we'll be less agile because of this, I think this is a good use of a definition of ready.
After all, your team has stakeholders you need to keep happy.
And when your promises to them about what you'll deliver are destroyed by my team not delivering to you, it's very reasonable for your teams to stop overlapping
work with my teams.
If you absolutely feel you need the definition of ready, I recommend structuring it as a set of guidelines rather than rules.
Consider a definition ready that says before anything can be started, any new or changed screens must be designed and the designs approved.
This rule will prevent overlapping work.
A better variation would be to say something like rough mock-ups of any new screens have been started and are just far enough along that the team can resolve
remaining open issues during the sprint.
This is a guideline.
It will still allow work to overlap.
The mockups need to be far-enough along, that team members think they can solve issues, during this sprint In some cases,
that could mean no more than a mock-up on a whiteboard.
In others, it could be an elaborate, nearly complete mockup.
Does your team use the definition already?
What's included in it?
And have you been able to continue overlapping work even with a definition of ready?
I'd love to read about your experiences.
So please share them in the comments.
And please do me a favor.
If this video has been useful, click the Like button.
and if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.