1 Simple Thing That Will Make Your Team Crush It

Originally posted on the Modus blog: https://moduscreate.com/blog/1-simple-thing-that-will-make-your-team-crush-it/

Is your team slow or do you think they could be faster? You can save them many wasted hours per week with a single short meeting called the Definition of Ready.

Learning what exactly is meant by a user story or ticket is a great hidden inefficiency in agile teams. Think about this scenario:

1. A developer grabs a ticket, reads it, doesn’t understand it well enough from the ticket to get started.
2. The developer messages the product owner who drops what they are doing and hops on a meeting to explain it to them.
3. There is something new that comes up regarding the designs because of the technical questions that hadn’t been addressed, so now the designer needs to get involved.
4. The developer then grabs the lead to discuss how to architect this because the original way they planned doesn’t make sense with new details.
5. Now they need to look into the pre-existing code, so a subject matter expert (SME — aka OG developer) meets with the developer to show them where in the code this will go and how the data is constructed.,

So in the end, this poor dev has now wasted a day, or possibly two. This has also severely disrupted the flow of two other developers (the lead and the SME) and a designer and pulled in the product owner who surely has a thousand million other things to do. And this process may repeat when our ticket goes to QA. The sad thing is that this can easily become standard operating procedure in many organizations.

We can fix this

Good user stories are the solution. But good stories don’t just happen, and good stories aren’t a one-size-fits-all proposition. A good story in one project can be a horrible story in another.

This is where the Definition of Ready comes in handy.

The Definition of Ready

The Definition of Ready is a team-specified set of general instructions that can help a product owner or business analyst write stories and gather the necessary information to craft stories that are workable without having to get further details. The key is to identify readiness criteria, which are the elements that are critical to determining whether a story is ready for developers to work their magic.

Stories in this context will generally include the simple user story — “As a {user type} I will {act} so that {purpose}”, the acceptance criteria, and anything else required for a developer to truly understand the story and its context.

The key is to express all criteria that are necessary while at the same time not over defining in a waterfall-like fashion. A story should always ultimately tell what, not how — but it should have enough information so the team will know exactly what it is and have what they need to decide how best to do it.

The DoR ceremony and documentation

The Definition of Ready ceremony is a simple meeting with all members of the team: project managers, developers (and/or dev-ops, dbas, other technical implementers), QA engineers, designers and anyone on the product team who participates in the story production. In my experience, this goes pretty quickly if the team has been working together on a project for a while and are familiar with one another and with the software they are developing. If you are working with a new team, I recommend waiting until the 2nd or 3rd sprint (about 4–6 weeks) before having this discussion so they can learn what is and isn’t necessary.

I generally will prime the pump by writing out some examples and discussing potential items that could affect readiness. I have discussed some of the following things:

• What are UI/UX requirements?
• Is there anything special about acceptance criteria?
• What would help QA writing good and comprehensive cases?
• Are there key dependencies that need to be noted?
• Are there regression points (areas that link to this feature) that will need testing or to be known when making changes to existing code?
• Is code being modified or created new and does that affect stories?
• Are there any tricks to getting to the state of the app that will be changed?
• Is this too much information or will the addition of one of these items create a bottleneck in development — either in fulfilling the need or in getting the information and writing it down?

Simply put, we are looking for what questions can be asked beforehand that will prevent the developers from having to ask them while they are in the flow of building. So the key in this process is to determine any potential inputs that can be accessed during story writing versus during development.

A Sample DoR

During the meeting, you can keep a running list of notes and suggestions, then work together to refine them into the final criteria. Here is an example of a final DoR from a recent project:

Definition of Ready:

The team agrees that for a story to be ready and brought into the sprint backlog, it must meet the following criteria:

1. A story in the form of As a <type of user> I want to <perform action> so that <purpose>.
2. Unless it is a spike or technical task, then should be a description of desired goal and necessary action.
3. Will have comprehensive and testable acceptance criteria.
4. Story should explain how the app gets to state required to test.
5. Story should include user credentials for testing, if user specific.
6. If necessary, permissions/packaging should be noted in story.
7. Design (UI/UX) should be signed off and ready.
8. The readiness of the API for a story should be noted.
9. If the API isn’t ready, the story should include data structure and test data in the same format as API will be.

Remember that this is a working document, meaning it should be addressed if and when anything ever changes and it’s a good thing to bring it to the team now and again to verify that it still makes sense given lessons learned at any point in the project.

Conclusion

Creating a Definition of Ready can help craft a solid product. It is a critical step in writing stories that enables team members to hit the ground running, saving the team a considerable amount of time and helping to deliver a better product.