Sometimes your Scrum team needs a little guidance on when a user story should be accepted into a sprint.

What is it?

The “Definition of Ready” establishes standards on preparing a user story and when it is ready or allowed to be accepted into a sprint. Basically, it’s an understanding across the Scrum team that the user story is understood and it is ready to be accepted into a sprint cycle.

Why is it important?

  • It helps the scrum team to clearly understand the user story
  • It ensures no dependencies or constraints are in place when a story is accepted into a sprint
  • It improves team velocity

When is it created?

If the scrum team has fallen into the trap where stories are unclear and velocity is not being maintained, then it’s time to setup criteria for what makes a story ready for the sprint.

Who creates it?

The Scrum Master should set this up with the Scrum team’s participation. It essentially becomes basic, standard operating procedure.

Example of a Definition of Ready

(1) Business value clearly articulated “As a ____, I want _____ so that _____” or similar format

(2) User Story includes acceptance criteria or ‘negative’ acceptance criteria.

“Given ___________________

When ___________________

Then ____________________”  or similar format that makes it easy for the story to be understood and completed.

(3) User Story includes screens (wireframes, comps and specs).

(4) User Story can be pointed with information provided.

(5) User Story points reflecting both dev & QA effort.

(6) Solutions should already be available and user stories can refer to solutions (i.e. architect software design).

(7) User story can fit into one sprint, or else it’s broken into tasks/sub-tasks across sprints.

(8) No external dependencies exist (such as API is not ready) which would block the completion of the story.

invest