When is a user story “ready” and when is it “done”

Use definitions of ready and done to make the most out of agile practices in your teams.

User stories, agile management systems and even planning poker are increasingly common in development teams, both by conviction and by fashion. These tools, if well used, can help teams make their best work — at Turpial Development we have seen the impact of these practices ourselves.

The entry point to these topics is usually the user stories, which are incredibly useful, but there are two small practices that take their impact to a whole new level: Definition of ready and Definition of done. While

Definition of ready:

The definition of ready, describes when an assignment or user history is ready to start executing — it is not that the assignment is ready, but we can start working on it, because we have everything necessary to begin.

In each project, this definition must be agreed (and kept in a visible place) according to the profiles of each of the members of the team and how they work; if it is not met, then the story is not added to the next iteration (sprint) of work.

The definition of ready can include things like:

  • The user story in the correct structure is complete:
    As <user_role> , I want <goal>, so that <purpose_or_motivation>
  • There is an explanation of the story / assignment
  • Everyone understands the user story
  • Acceptance criteria are written and understood by all
  • There is an agreed interface design goal defined up to a specific level

Definition of done

Similarly, the definition of done describes when we can consider that a user history has been completed. This helps maintain the quality of work throughout the project and provides a shared criterion among all parties about when a user story has been completed.

The definition of done may include:

  • Document new functionalities, views and APIs
  • Fulfilling acceptance criteria or passing all acceptance tests
  • Pass design implementation review
  • Pass automated tests

Make pull-request to the dev branch and have it approved


It is not an unusual experience that, due to the lack of Definition of Ready and Done, some processes degrade to a situation in which the team seems to follow agile practices, but only on the surface, without a real impact on how they are organized and deliver results, which hurts the projects by dedicating time to processes and meetings without a clear impact in productivity or quality.

Both the Definitions of Ready and Done help to make the most out of the user stories in teams that want to work with agile practices.


This post was originally written in spanish to clarify translations of these terms, in addition to explaining the concepts.

These definitions receive less attention compared to other agile practices where Spanish is the spoken language; perhaps because done and ready are have ambigous translations in that language, listo is the closest translation to ready but it's often used as a synomin of done.
It's really worth applying these practices in future projects, wether or not you have to explain the concepts a little bit more beacuse of the language.