Definition of Ready in Dependent Relationships

Natalie Warnert (@nataliewarnert) blogs at Confessions of a New ScrumMaster.  Here she is… The Definition of Ready is a concept that is gathering more momentum within Scrum. Where it likely sounds most familiar is from the “Ready” state in Kanban development. You obviously would not pull a Kanban story to “In Progess” if it was not already in the “Ready” queue. The same should be true of stories on your Scrum backlog. But the challenging part is there may be differences in what each story needs to be “ready”, especially at different stages of the feature with dependencies on other teams. Getting to ready should be happening during backlog grooming one to three iterations ahead.

My dilemma comes into play with the uniqueness of my team. It is not a development team – we’re not producing working tested software. My team is a depended on team at the front of the Definition of Ready for the development team in conjunction with the Product Owner. It’s a User Experience (UX) team that is very specialized in what we deliver. I plan on doing a post in the future about how I’m using Scaled Agile Framework (SAFe) methods to build a UX runway into Scrum but that is a different story. My team consists of UX researchers, information architects (IA) who produce wireframes, visual designers who create high fidelity mock-ups, and CSS developers who style the front end and pay attention to accessibility after it’s developed by the development teams. Because of the specialization and our place not only at the front of the chain but throughout, there are many hand-offs and approvals between team members, Product Owners, and development teams.

So back to Definition of Ready…There should be a separate ready state prior to each hand off I mention above. In development teams that do not have dependencies that ready state is simplified: they need “just enough” information from the Product Owner to start coding. How much “just enough” is can vary by the team, the story, and the information available. Obviously a spike story would have less information needed than a child story of a large feature that has been being discussed for a few iterations. As for my team it’s a bit different.

My Definition of Ready needs to be defined in several different places:

1. Product Owner to IA and visual designer – Do the requirements represent how the user flow should function? Is the acceptance criteria indicative of when the wireframes are detailed enough? What colors and styles should be used? Should the product be modeled after another one?
2. IA to visual designer and development team – Do the wireframes show how the user will use the system and how the system will react? Do the wireframes show all possible scenarios, errors, and user interactions? Is there enough detail for the development team to write and add to their stories?
3. Development team and visual designer to CSS developers– Is the development work completed enough to be visually styled? Have the user flows on the wireframes been followed in the system? Are the visual designs complete with extractable, high quality images and explicit colors and measurements?
4. CSS developers and development team to QA team – Have all pieces of code been unit tested for styling and functionality?

I know what you’re thinking – that’s a lot of hand-offs, and a lot of process. The handing off team’s (dependee) Definition of Done is the same as the handing to team’s (dependent) Definition of Ready. As I previously mentioned, the Definition of Ready may not be the same in all cases. Though I am certainly not a person who makes process for process’ sake, I found that the team was doing most of these things naturally with a few exceptions. The largest issue I have been running into is the initial Definition of Ready between the Product Owner and IAs and visual designers. In this complex world of scaling Agile, especially when my team is introducing a new way of working and dependencies for development teams, it gets complex quickly. The Product Owner is used to writing stories for the development team. A Product Owner concentrates more on what the system should do, and not as much how the system should do it. As many Scrum teams know, it’s usually up to the development team to determine the best way to develop in. By inserting UX into the middle, it creates more structure and consequently more rigidity around the previous “freedom” to develop. However, it also contributes to more intuitive and usable products going to market. In this case we need to move from “the system should do” to “how the user will do it.”

My hope is that by keeping it in the open and changing the Product Owner view of UX, it will be a constant reminder to think (as in the Definition of Done) is this “ready” to be wireframed and designed? And from a development team perspective, do we know “just enough” about the user interaction to start coding the feature?

–Credit to Leslie J. Morse for the “just enough” idea, Davis Base Consulting has a great Definition of Ready post on this, too. –Check out this great Definition of Ready article by Serge Beaumont

This post first appeared in May 2013 as Definition of Ready in Dependent Relationships at Natalie’s blog.