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 work 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:
- 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?
- 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?
- 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?
- 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?
Thank you all who attended my talk on Confessions of a New ScrumMaster. I really enjoyed speaking to the group and answering the great questions at the end. The slides are available here if you would like to download them. You can view the original Confessions of a New ScrumMaster article here. This was the largest gathering in Scrum Gathering history with over 500 attendees with about 70 percent being first time attendees! Even with the increase in participants, the setting was still intimate enough to make lasting connections. Though the “party” at Margaritaville was a little over the top for my style (Agile2012 won in this area), it still had good food and a couple free (strong) drinks. It was certainly my favorite conference to date. Check out the Scrum Alliance website for other upcoming events.
Some other notable presentations from the Scrum Gathering I enjoyed were:
- Breaking Analysts: A Real-World Tale of Converting a Traditional Business Analyst into a Lover of Scrum by Leslie J. Morse. This was a great session from the perspective of a BA, which is often not discussed. Leslie made some great points about BA fears and how to alleviate them when implementing Scrum. She also made some great remarks about having “just enough” detail to start a story and defining a “Definition of Ready” which is something that hits very close to my heart and my Scrum team. I might even do a post about it soon! It was very well done and she will be presenting it at Agile2013.
- Coach the hand you are dealt. A True Agile Approach to Coaching by John Miller. John is the creator of Agile in Schools (and will be presenting it at Agile2013) and had a thoughtful talk regarding what coaching is actually defined as versus consulting. It certainly made me think about my qualities as a coach and how I can improve my skills to allow teams to solve their own problems instead of leading them toward the answer I would give.
- Stop Gambling, Embrace your Agile Superpowers by Jake Calabrese and Stephen Starkey. There are hardly words for this session. It was extremely powerful and moving to do this activity and I have only the highest praise for Jake and Stephen on their phenomenal facilitation skills. The concepts were derived from meta skills by Arnold and Amy Mindell, CRR Global and the Agile Coaching Institute.
- Facilitation & Communication in Scrum Teams by Michele Sliger. Michelle had some great activities to get people up, moving, talking, facilitating and leading. Her enthusiastic personality and practical application made the 90 minute session fly by!
There were also some great Open Space topics with Adam Weisbart facilitating. My personal favorite topic: Women In Scrum. A great group of women got together to talk about how to attract more women to Scrum and how to continue to make our voices heard. Please contact me with questions and I will update as more details emerge around a Women In Scrum user group.
I look forward to the upcoming conference: RallyON! June 3-5th 2013 in Boulder, CO. Hope to see you there!