Here’s a video I shot for freeCodeCamp about the Definition of Ready.

Have you ever started work on a user story that wasn’t ready to work on yet? Create a Definition of Ready to establish reasonable guidelines as to what conditions need to be met before you pull a user story into a sprint or begin work on it. Creating and following a Definition of Ready could double the speed of your team.

Click “Continue reading” below for a transcript.

Hi, my name is Chris Gagné and I am an Agile Coach. Today, I will talk about the Definition of Ready.

The Definition of Ready is a documented team agreement. It defines the conditions that must be met for a product backlog item to be considered ready to work on by the team. It’s not a formal contract or approval gate but rather as a set of guidelines that will help your team make a good tradeoff between minimizing risks and getting started.

Creating and following the definition of ready diligently can easily double the speed of an Agile team because the team can stay focused on shipping working software, not chasing down requirements. For a real world example, think of the “mise en place” or “everything in its place” concept used by chefs and cooking shows: before they begin preparing the recipe, they carefully organize and measure the various ingredients so that they are immediately at hand while cooking. A little careful preparation goes a long way.

A good starting point is the “INVEST” mnemonic, to which I like to add a “U” for “U-INVEST”.

U stands for User Experience, which includes research, wireframes, mocks, written content, and even visual design. Mature Scrum teams with dedicated designers can research, design, code, test, and ship within a single two-week sprint. If you can’t, consider making user experience a prerequisite for development work beginning.

I means Independent, the backlog item should be self-contained, in a way that there is no in-sprint dependency on another backlog item.

N means negotiable. Until the sprint formally starts, the development team and product owner can negotiate on the nature and scope of the item. Once the sprint starts, the product owner should not materially change the acceptance criteria.

V means Valuable. A backlog item must deliver value to the stakeholders. If you can’t clearly articulate the value for the work, you shouldn’t do it.

E means Estimable. The team must be able to estimate the size of the backlog item, ideally using story points. Otherwise you won’t be able to effectively manage your flow of work.

S means Small. Ideally, the backlog item should not take the team more than half a sprint to complete.

T means Testable. The backlog item should include enough information to make test development possible. For instance, “The coffee should be between 120 and 130 degrees fahrenheit” is a clearer acceptance criteria than “The coffee should be hot.”

Create your Definition of Ready as a team based on your unique needs. Review it at each backlog refinement and sprint planning meeting. You can update your definition of ready at any time so long as the team agrees to the change.