"Mise en place"—every ingredient prepped and ready to be used—is the mantra in the kitchens of top rated restaurants around the world. In agile software development, mise en place is also key.
Taking the cooking analogy a little further: In a design and development “recipe” there are generally several ingredients working together that make a delicious digital product. One that your target customers will rave about and want to devour. But how do you know you’ve got the right amount and the right quality of ingredients so you don’t end up with an unappetizing, strangely-colored mush? You do it by having the right cooks in the kitchen. And also by knowing your “Definition of Ready”.
Does your team have a Definition of Ready? Can you articulate what it is?
Simply put, a Definition of Ready is a set of guidelines that the team can use to decide if the task is ready and if not what gaps exist. Different teams may use different definitions of readiness. For some, it is a checklist and for others, it’s a statement of an ideal to aspire to. Every team member should know their team’s Definition of Ready so that all are working from the same baseline, and so they can identify gaps as early as possible.
At Freeport Metrics, our Definition of Ready includes such conditions as:
- Must have a complete user story
- Must have visual designs / mockups / wireframes
- Must have Acceptance Criteria
- Must have been estimated
- Must be no more than (x) points/hours
- Must not have unresolved dependencies
There are a range of opinions on whether a Definition of Ready conforms to agile principles. We believe it to be an essential communication tool for our teams. Like most concepts its success depends on how it is implemented.
So we have our detailed tasks to form the ingredients list that come together to form our development “recipe”. In general, let’s say it’s something like this:
- Product Owner writes user story
- UX designer creates designs
- Product Owner and/or QA write acceptance criteria
- Developers estimate
- Ticket is READY
- Build thing
- Thing makes world better / makes you billions of dollars
Your workflow might include other steps such as stakeholder or client approval. Regardless, the concept is the same: Each role contributes something to the recipe that is unique to their skillset and vantage point. In theory, each person can do their part without ever needing to have a conversation with another team member. You can go down your Definition of Ready checklist and see that all the ingredients have been thrown into the pot. Herein lies the problem: this approach doesn’t guarantee that the ingredients are of the right quality.
Utilize your team’s talents
If you’re using an agile methodology, you’re already (in theory) being iterative in your development approach. Why, then, would you not also be iterative during design and planning?
In real life, user stories don’t often follow the happy path. More likely, there’s something of a feedback loop. Maybe the developers have a simpler solution and should talk it over with the designer and Product Owner. Maybe QA thought of something the Product Owner didn’t. Maybe there’s an external or back-end constraint that prevents the design from being implemented as conceived. Maybe somebody changed something in another feature and now the design doesn’t work.
So what do we do next? Let the team inspect each other’s inputs, with each person bringing their unique perspective and talents, to maximize the quality of the whole.
Don’t forget to have the conversation!
Time for an agile principles refresher: the most efficient and effective method of conveying information within a design and development team is a conversation.
A user story is a promise for a conversation-Alistair Cockburn
So here’s the important bit: don’t forget to have it.
Depending on your organization, having conversations about readiness between team members is sometimes easier said than done. Often, designers, developers and product owners are not in the same location and may be in different time zones, which means it’s not always easy to schedule meetings. It can be tempting to use documentation instead of conversations. At Freeport Metrics, we are heavy users of collaboration tools like Slack, shared document edits/comments and, of course, email. But when we can we prefer to have a live conversation.
One method we use is to organize regular backlog grooming meetings. This has become a pretty common technique for agile teams. For us they are an opportunity for the whole team to inspect stories and tasks, break down epics, and improve the quality of the contents. Once the team is satisfied, the story can be marked as Ready.
So what’s my Definition of Ready?
To summarize, my definition of ready is more than a checklist, or a set of Rules That Must Be Obeyed. It’s softer than that and more interactive. It’s this:
Every "role" on the team has looked at the feature, understands it, and has had an opportunity to raise questions. All known questions have been answered. The requirements and design have been tweaked according to what was discovered during this process.
If you’ve done that, then you can feel confident about the contents. The recipe - and thus the outcome - is only as good as the quality of the ingredients.