Managing Definition of Ready in TFS
--
Along with Definition of Done, the Definition of Ready is a crucial concept for Agile teams.
Never pull anything into a sprint that is not ready, and never let anything out of the sprint that is not done. — Scrum Alliance
When our team began to adopt Agile, we frequently ran into User Stories that were not Ready-ready, which wreaked havoc within our iterations. Halfway through a sprint, we would discover unknown requirements, confusing UI descriptions (when you are describing a UI, that should always be a warning sign), or missing dependencies. At the end of a sprint, we would be about to deploy new features, only to discover that no one had written the necessary copy for the website or trained customer support on the change.
There was no one to blame but ourselves. After all, we had all agreed to the sprint, thinking that the body of work was ready for development. We realized that we need to formalize our team’s Definition of Ready.
As a small development team within a lean-running company, we created a Definition of Ready that is probably more involved than larger teams. Once we begin a sprint, we don’t have dedicated BA, UX, or UI personnel who can work alongside our developers. Further, we had run into the same issues frequently enough to identify specific issues that, for whatever reason, often caused us problems during a sprint. We landed on 10 tasks that needed to be completed for a user story to meet the Definition of Ready for our team:
- Define and agree to the user story.
- Define acceptance criteria.
- Identify any dependencies.
- Define user experience.
- Estimate the size of the User Story.
- Create and approve mockups/UI.
- Identify training needs.
- Identify marketing and communication needs.
- Identify content needs.
- Determine who will approve User Story
Not every user story requires every Ready Task to be completed. For example, in some cases, there is no content that needs to be created. But every task must at least be considered. If we decide that a task is unnecessary, that must be a conscious decision, not an assumption.
Tracking the Definition of Ready
With up to 10 separate tasks for every user story, we recognized immediately that keeping track of their completion was going to be a challenge. So we adapted our existing project management and reporting tools for the job. Our team already used TFS for project management, so I made a few customizations to fit our new Definition of Ready.
In TFS’s Agile project template, User Stories serve as the parents of Tasks. Out of the box, a Task can be assigned to an Activity category such as Requirements, Design, Development, or Deployment. As a first step of our customization, I created a new Activity type— Ready — to capture the ten Definition of Ready Tasks. Now, these Tasks could be created, assigned, and tracked just like any of our other development tasks.
TFS tracks not only the stage of a Task — i.e. New, Active, Completed, Removed — but also the reason why it has been moved to that stage. So I also created a new reason for setting a Task to the Removed stage — Unnecessary — so that I could track Ready Tasks that had been deemed unnecessary for a particular User Story. This removes the Task from our to-do list, but continues to let us monitory its status, in case anyone wonders why a particular Task was not required for a particular User Story.
Next, I created a Phrase Express snippet (which is like TextExpander for Windows) that enabled me to quickly add Ready Tasks to a User Story. I have a saved query in TFS for all User Stories that need to be gotten to Ready, which shows both the User Stories and any child Tasks they have. When I need to add new Ready Tasks to a User Story, I open the query in Excel and use the Phrase Express snippet (or copy-and-paste) to add and publish the new Ready Tasks.
As we complete Ready Tasks, we add the details of the Task to the Description body of the User Story. If any files are created by the Task, we attach them to the Story. By the time a Story achieves the Definition of Ready, everything that a developer needs to know — well, almost everything — has been captured within the Story itself.
Monitoring and Communicating the Definition of Ready
Now that we had a way to create Tasks for the Definition of Ready, we needed a way to monitor them. In the User Story definition in TFS, I created two new custom fields — Ready Done and Ready Remaining — to capture the number of Ready Tasks that had been completed and the number that were remaining.
Now I had some numbers that I could use for reporting. In the report that I use to communicate the status of our User Stories to the rest of the company, I added a column to calculate the percentage of Ready Tasks that have been completed for each User Story. We meet weekly as a team to discuss any User Stories that have met 100% Ready status, to determine whether they truly are Ready. If we all agree, then I move them to a new state in our Kanban board — Ready — to show that they can be pull forward into the next sprint.
At first, I sorted the report by percent of tasks completed, thinking that it would be helpful to see User Stories rise to the top of the report as they got closer to Ready. After a few months, however, I discovered that it was easy to overlook high priority User Stories that were being neglected. They stayed at the bottom of the report, which often was never even discussed in meetings when we ran out of time. So I reordered the report to list User Stories by their Area (to group like-with-like), then by their Priority and Stack Rank. Now, high-priority Stories with low Ready scores become highly visible — if a team member’s highest priority Story is setting at the top of the list with a big fat 0% in the Ready column, that becomes a topic of conversation.
Further, because we track individual Ready Tasks, we can pinpoint exactly what we’re waiting on. If a Story is at 90%, we can open it up and discover that we still waiting for the mockups to be approved or the content needs to be defined.
The Benefits of Being Ready
The system is not perfect, and it isn’t meant to be: it’s meant to be useful. I’m a big believer in the Kanban principle of continous, iterative improvement for our processes. For example, after using the system for a couple of sprints, we realized during a retro that we had a distinct genus of “internal improvement” User Stories that could be defined and agreed upon just by our development team. So we created a smaller batch of Ready Tasks that omitted UI, content, marketing, and a few other Tasks. One day, I hope that we discover that a few of the Ready Tasks have become an integral part of our development process and no longer need to be explicitly called out.
Since adopting this process, we’ve noticed three significant improvements to our development. First, as intended, it has dramatically cut the number of “half-baked” User Stories that make it into our sprints. A few still slip by — usually due to my overconfidence in the team’s understanding of a Story. Those, however, have become the exception rather than the rule.
Second, the speed and efficiency of our work during the sprint has increased. While we still communicate with stakeholders throughout the sprint, we now have a much greater amount of the information about each User Story already gathered. Mockups, UX, acceptance criteria — when a developer opens up a User Story to begin working on it, he finds (most of) the pieces of the puzzle already assembled. It’s a bit like a craftsman who lays out all of his materials before a project begins, so that he doesn’t have to stop work once he starts.
Finally, the morale of our team has improved. We no longer dread opening a new User Story with a deceptively simple title, because we already have a fairly good understanding of each Story in our queue. We have to stop work to gather more information much less often, and almost never over trivial issues that should have been decided long before.
Managing Definition of Ready within TFS has been a great success for my team. We have managed Definition of Done with a much less developed system so far, and I expect this will be one of the next process improvements that we tackle.
