Definition of Ready (DoR) in Dependent Relationships

Definition of Ready (DoR) in Dependent Relationships

May 20, 2013 Scrum Methodology User Experience (UX) 5
Definition of Ready

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 depended on by the development team at the front of the Definition of Ready 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

–Republished for Women In Agile at Coaching Agile Teams blog by Lyssa Adkins


5 Responses

  1. […] post first appeared in May 2013 as Definition of Ready in Dependent Relationships at Natalie’s […]

  2. […] So I’ve alluded to a UX runway and my work with Agile and UX in some of my previous posts, but what does that mean? Agile has been the buzz for the past decade and UX was quick behind. First, let me give some background on UX and my role on the team. I’m the ScrumMaster of a UX team. We are part of a large organization serving the needs of many legal application development Scrum teams. My team consists of user researchers, information architects (IA), visual designers, and CSS developers. For better descriptions of these roles please see my post about the Definition of Ready. […]

  3. john miller says:

    Great Post! It helped my with a client who uses an external UCD partner!


  4. Amol says:

    Thanks for the informative read. Within UX work , there must be many end users whose inputs are built into the product backlog.
    I have heard many challenges on the following front:
    How do you manage to get these end users feedback?
    Is it within the sprint? what happens if the feedback triggers changes in the prioritized stories which are already passed to development?
    What is end user reaction to demoes once development team complete work but could not incorporate end user feedback within that sprint.

  5. […] fleshing out the requirements into something actionable. In this project instance, there was not a Definition of Ready or and business analysts to help the Product Owners in defining their requirements. This led to […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.