A key benefit of agile development is the in-built flexibility and responsiveness to change. But it is very important that responsiveness doesn’t destabilise the team or organisation; that the team can be flexible “as usual” in a controlled and stable way, rather than having to resort to extraordinary measures that are not sustainable.

Group of people discussing around a table, with pens and post-it notes

So agility, flexibility or responsiveness does not mean that every item on the backlog can be allowed to change all the time – at some point, a task that is going into development needs to be fixed so that the team has a static set of goalposts to aim at. This article will explain some of the constructs we recommend to mature tasks in a transparent way, that fixes tasks at the right time but retains flexibility at all other times.

Working backwards: Definition of Done

The most fundamental construct is the Definition of Done. The 2020 Scrum Guide describes the Definition of Done as a commitment:

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product… The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration… The Developers are required to conform to the Definition of Done.”

So a Definition of Done is a definition, across the project, of what a completed piece of work (e.g. a feature or answer to a user story) looks like. Adhering to that definition means that all work that is necessary is consciously done, before moving on to the next task, and working to that definition gives a consistent level of quality across the project. Building a Definition of Done means describing the general conditions that must be met before a piece of work (task, feature, bug fix, increment etc.) can be released to the users. In many instances, a piece of work is not done until it is fit for immediate release to the user – otherwise, more work would be needed before the user can start getting value from it, hence it is not done.

Establishing this definition for a project or product is a critical step in establishing consistent high quality output. It aids transparency and predictability through the ability to plan against a known end goal. It can also be the start of a framework to describe and manage the maturity of backlog items. Ian Mitchell writing for scrum.org describes how “done” is built up gradually as work on a task is performed. This means that the maturity of the task is built up as it goes through the different roles in the team. For example, a task or ticket could be formed as a user story describing an idea to improve a user’s experience in a journey, or give them a new capability. It may start out as just an idea – so how does that story get matured by the team to be well understood, with the needs and benefits established?

Meeting room with people at a table and one person sticking post-it notes on a glass wall

What comes before done: Definition of Ready

So you know what the end goal looks like by having an agreed, descriptive definition of done. But how do you know when you are good to start development? The Definition of Ready is influenced by the Definition of Done, and what that specifically means for your project, product or team. The Definition of Done defines the end point; the Definition of Ready works back from that to understand what needs to be in place for developers to start developing a solution to meet the various needs, and meet the Definition of Done.

The Definition of Ready generally takes “ready” to mean “ready to start production development work”. The general theme of a Definition of Ready is that the team knows enough about this task / backlog item to start work on a stable problem, e.g. to take into a sprint. Note that in line with agile working, the requirement will need to be flexible at other times in the project, specifically before it works its way to the top of the backlog, ready to be considered to take into the next sprint. However, to give the development team a fixed set of goalposts to aim at within a sprint, the requirements have to be fixed just before they are taken into the sprint; any significant changes to a requirement may require it to be pulled out and further matured in discovery, before it can be considered for inclusion in a future sprint.

There are many potential aspects that may influence a Definition of Ready, depending on the nature of the product or project. Some of these could include understanding whether the team knows enough about:

  • The user, their needs, motivations and frustrations.
  • The user’s context and what they are trying to achieve, and how the user will get value from this – and what is either side of this story.
  • The context of the system(s) in this part of the journey and relevant to this item.
  • The business logic needed to accomplish this.
  • The interfaces needed to accomplish this item, covering both user interfaces and system interfaces (e.g. APIs).
  • If the backlog item is well-written (e.g. a user story that conforms to the INVEST criteria).
  • The technical approach and solution to accomplish this.
  • The acceptance criteria and “how I know when I am done” – how will the backlog item be tested and what does good look like.
  • The estimated size of the task.
  • The likely stability of the relevant aspects over the duration of the iteration / sprint that the item will be worked on.

This is a long list, and may be too long for the context in which you are operating; the aim of the list is to suggest aspects for your team to consider when drawing up their Definition of Ready. However, at a minimum, the Definition of Ready should include:

  • A well defined user.
  • A well defined and written need (e.g. a user story conforming to INVEST criteria).
  • Clear and understood acceptance criteria.
  • An agreed estimate.

Scrum definition of ready

The Scrum Guide doesn’t include a formal description of the Definition of Ready in the way that it does for Definition of Done. As a result, different Scrum organisations have attempted to fill that gap with numerous variations on the theme.

From scruminc.com:

“Having a Definition of Ready means that stories must be immediately actionable. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or Product Backlog Item.”

Leading Agile says that:

“The definition of ready provides clarity to a product owner or product owner team on what it means to create ready backlog items.”

Roman Pichler describes ready by saying that:

“A ready item should be clear, feasible and testable… A story is clear if all Scrum team members have a shared understanding of what it means… An item is testable if there is an effective way to determine if the functionality works as expected… A story is feasible if it can be completed in one sprint, according to the definition of done.”

It is clear that while individual Definitions of Ready can differ, the themes are very similar; when I know <these aspects of the item>, I can be confident that the item is actionable – and ready to start now.

You can take advantage of this flexibility to agree on a Definition of Ready that is tailored to your project or product, and then make that transparent across the team and stakeholders to help each item have a stable and good quality starting point.

Maturing requirements in an agile way – Checklist of Readiness

If you are used to waterfall development, then having definitions of Ready and Done could sound like gateways that split an agile process into more of a series of mini-waterfalls. It is definitely not the intention to promote hard and fast, cannot-go-back phases of development, as this removes agility. Instead, the definitions are intended to be used as markers of the maturity of a backlog item, and to help the Product Owner manage the backlog and their and the team’s discovery work. These are readiness levels, and do not intend to mandate how a team goes about increasing that maturity to the level needed to start development. Work to increase a ticket’s maturity level does not have to be done in rigid steps, but should be managed flexibly to achieve the right level of overall maturity at the right time, retaining agile practices such as collaboration, iteration, feedback, and deferring final decisions until appropriate.

Group of people in front of an ideas pad having a discussion

With that in mind, you can extend your Definition of Ready to include a checklist of how to get there. At Box UK we are great fans of checklists; they can describe and shine a light on where you are in a process compared to where you need to be, without constraining a team on ways to get there (and we really are fans, using checklists in everything from code reviews to website launches). And they are a great memory aid for important processes! The items on that Checklist of Readiness may vary in detail depending on the type of product or project you are working on, but should encapsulate what you need to do to create a great outcome, embody the values of your organisation, and be consistent for the life of the product/project. In this way, you can keep track of the maturity of each backlog item, without restricting your team to a single order or path of exploration to mature the item to Ready. The diagram below shows what could go into your Checklist of Ready, to get an item to meet the Definition of Ready – and how this connects with a Kanban board to track development progress through the iteration or project.

Diagram showing example Checklist of Readiness items: Spike - experiment for development solution, Estimation, Needs UX/Design, Needs Analyst Refinement, Story Time, For Discussion with Client, Needs Discovery

As the team matures the backlog item through agile discovery, so each of the areas in the Checklist of Readiness will increase in maturity, until they meet an agreed level for development to start. Tracking these aspects as a checklist helps to visualise the areas in which a requirement has been matured, and where further maturation work is still needed.

The Definition of Ready can come with a hidden danger, which sits in a nuance of the word “Ready”. As we’ve previously mentioned, we generally think of “Ready” as “ready to start production development work”. But that doesn’t (and shouldn’t) mean that you can’t ever do any development work to mature a backlog item ready to go into production. For example, user feedback and behaviour may suggest a new feature – but what happens if that new feature requires or makes use of a new technology that the team is unfamiliar with? It is often legitimate to explore that feature and technology by building a small proof of concept to learn more about the problem, the solution, and the technology in that solution. Such exploratory building or development is not subject to the Definition of Ready in order to start – it is part of the maturation process that brings a backlog item to the right level of maturity to build a production solution.

Where the Definition of Ready and Checklist of Readiness can help you

The Definition of Done is a fundamental commitment in the Scrum Guide; even if you are not following Scrum, having and using such a definition can help your team reach and maintain a known and agreed level of quality. Every project and product should have one.

The Definition of Ready is not a fundamental commitment in the Scrum Guide, but it can be hugely helpful in maintaining quality and efficiency of development, in particular a stable velocity for a given team (we’ll talk about velocity in another post, soon). Understanding and meeting the Definition of Ready can reduce the need for rework. We highly recommend that every project and product should have a Definition of Ready, and apply agile discovery approaches to get there.

The Definition of Ready is about sensibly reducing the risk of waste when you start a production development item. You are not trying to eliminate that risk altogether – this will lead you back to waterfall levels of analysis that often translate into high levels of waste in themselves. But you are trying to reduce (to a sensible and agreed level) the probability of an item needing unnecessary rework because the team “doesn’t know enough” about one or more aspects of the problem or solution when it starts production development work on it. The Definition of Ready draws a line at that acceptable risk level. Inexperienced teams may be advised to consider the Definition of Ready as mandatory, at least to begin with. This will allow the concept and its execution to mature within the team; as with all things in agile, teams are encouraged to inspect their decisions and processes and adapt them where that would bring improvement.

There are tradeoffs in where you draw the line of “Ready”, and in experienced teams, with the discretion and agreement of the Product Owner and team, items can (by rare exception) be allowed to start production work if the story is “mostly” ready – generally if the risk of starting a story is lower than the risk from not starting the story at that point. A classic example of this, in an agency environment or if you are integrating more than one product, is a solution within one product that has a dependency on something from another product or system, for example an API call to source or deliver data. If that API is also undergoing development in parallel, maybe by a third party, then there is a dynamic dependency. Here is the dilemma – do you wait for the API to be finalised before you start work on the product feature? That would give the stability advised by the Definition of Ready. But if the API is owned by another party, then you will not have control over its development or the timescale – you may end up waiting so long that you miss the opportunity that prompted the feature requirement in the first place. So do you carry some of that risk of rework to go ahead and start developing your feature in the knowledge that the associated API may change while you are working on the feature – but with the potential payoff of getting value to your users earlier than you otherwise would? While a Definition of Ready and Checklist of Readiness should not mandate an answer, it should give you an insight into the areas of maturity of the story and where any risk lies, so that you can manage that risk more closely, and make a more informed judgement of whether you should start development on a particular backlog item.

Where might a Checklist of Readiness help? A few years ago, a Product Owner colleague was working on a large website project that was at the centre of the client organisation’s digital transformation. The website was for a large professional membership organisation, covering a vast range of topics necessary for that profession, at multiple levels of depth, with a large number of client stakeholders and user groups. Managing these large groups and the resulting wide range of perspectives and needs, in order to collaboratively capture and mature those needs, became very complex. In this situation, the Product Owner led the team in breaking down the components of what makes a requirement mature, shining a light on them and representing them as a checklist, and managing progress through that checklist as part of backlog review and management work. Getting the picture of maturity out of the Product Owner’s head and into a construct that was visible to the team and clients allowed team members and stakeholders to more easily identify the most beneficial work to do next. Although this took effort mostly on the Product Owner’s part, the payoff was the visibility gained in the areas of each requirement that needed maturity, and the resulting simplification of planning collaborative requirements workshops, increasing their effectiveness and significantly reducing the apparent complexity within the project.

Product Owner during workshop session

However, not all projects may be large or complex enough to achieve a net benefit from a Checklist of Readiness and the effort required to define and maintain it. Our advice would be to experiment by using the construct on a project, inspect its impact on the project, and adapt your approach accordingly.

So, are you ready?

Having an agreed Definition of Done can guide team members in assessing the maturity of their work to date and how close they are to finishing and delivering a production-level piece of work. Having an agreed Definition of Ready can guide the Product Owner in managing and executing the collaborative discovery work needed to understand the piece of work that team members will be asked to do. Having a Checklist of Readiness can help the team and stakeholders understand the variation in maturity across a project or product backlog, and this visibility can significantly aid in prioritising and managing discovery/de-risking and development work; it is particularly effective in larger or more complex projects.

At Box UK we have extensive experience supporting organisations in their Agile transformation journeys – identifying opportunities for improvement, solving problems and delivering objective and tangible business benefits. See how we’ve helped other businesses evolve and grow, and contact us today to find out how we can help you.

About the Author

Andrew Beaney

Andrew is Box UK’s Managing Consultant, specialising in coaching and consultancy, Agile Business Analysis and Product Ownership, team leadership and change management. He has a track record of delivering technical advice and reducing business risk, working with a broad range of information systems and technologies for over 20 years.