Why the 3 Columns of “To Do, Doing, Done” Aren’t Always Enough
On a recent project, I noticed that our previously high-performing Scrum team was sputtering. We were missing an increasing number of sprint commitments, and none of our retrospective suggestions were improving performance. In fact, retrospectives often turned into constructive critiques, where we were examining resource utilization, development/QA processes, requirements, and estimation tactics in an effort to improve efficiency. I often felt like we were guessing at ways to improve, without any empirical evidence to support our suggestions. All we knew was that leftover tasks sat in the “doing” column on our board for days on end.
After scanning through our stand-up notes and task board comments, we discovered that our problems were surfacing well before diving into epics and stories in the columns themselves. By adding transparency into the way our team reported on its progress through additional columns, we found it markedly easier to discover and clear previously unknown roadblocks during our retrospectives.
Beyond the Limits of the Three Columns
Agile/Kanban practitioners often speak of their task boards as project control rooms, where a well-organized board helps teams efficiently plan, visualize and manage work while overcoming a variety of collaboration roadblocksespecially when dealing with distributed teams and/or part-time resources.
One of my favorite tools for quickly standing up project task boards is Trello, an implementation of Kanban that reduces workflows down to their simplest form in its default template: “To Do, Doing, Done.” In practice, these columns are usually adequate for feature development and delivery. After spending some time with this workflow, however, we found that tasks that aren’t as simple as we initially thought. Indeed, most tasks inevitably spend most of their lives living in “Doing,” with very little transparency into their status outside of tool-hosted comments and regular stand-ups.
Before embarking on your next iteration, consider adding some of these columns to your workflow:
-
- Analysis/Research: it’s not always immediately apparent how a task should be completed properly. Although design and UX work should be completed by this point, a developer may need to consult documentation, discussion forums, other developers and/or previously completed work before diving into development. While most tasks should (by this point) have a relatively clear path toward implementation, it’s useful to track these types of discussions and note how they help (or possibly hinder!) overall development. If your team is spending too long on this phase, you may need to hold larger-scale discussions focused on priority and scope.
-
- Setup/Preparation: Okay, so you’re ready to start development… but your environment libraries are out of date and there are merge conflicts from upstream/master. Technically, the task is in “Doing”… but it hasn’t actually entered development yet. These tasks can live in a Setup/Preparation column, which is a great place to look after an iteration for possible improvements.
-
- Review (Development Done): one of the major pitfalls of the three-column approach is the risk of having tasks live in review (peer, QA, UAT) for considerable amounts of time. “Ready For Review” means just thatthe work has been completed, but hasn’t been peer reviewed yet. This column lets the developer move on to the next priority item and assign a reviewer, without having to provide direct oversight on getting the task into “Done” status.
-
- QA (Review Done): similar to the above, but for the hand-off between “Peer Review” and “Ready for QA”. This column ultimately serves as the QA “to-do” list.
-
- UAT (QA Done): tasks that are ready for Product Owner acceptance live here. Those that fail the acceptance criteria are sent back to the “To Do” column to be fixed / addressed. Tasks that fail in this column may indicate that specific requirements are being lost in translation (and/or tasks are not being created with clearly defined acceptance criteria).
-
- Ready for Release (UAT Done): tasks that have passed all stages of review and approval. This typically means merging the work into a stable branch. Tasks that live in this column for longer than expected may indicate potential improvements to your deployment processes.
-
- Released (Done): tasks that have been deployed and are available for all to see the job is (hopefully) done!
Cautionary Note: While the addition of some (or all) of these columns to your task board may give you more insight into your team’s overall efficiencies, be wary of introducing a waterfall-like, linear sequence of development. Continue to foster team collaboration across columns to avoid silos of responsibility and keep your team engaged throughout the entirety of a task.
Always Keep the Focus on Continuous Improvement
Ultimately, visualizing the numerous steps of a task in the ‘Doing’ column may help you identify the areas where you can improve your team’s processes. Striking a balance between over-simplification of your workflow and providing adequate detail into your team’s processes may be the key to figuring out where the inefficiencies lie. Above all, your task board should continue to evolve over time as you build a clearer understanding of your team’s processes.
While not every column is right for every situation, adding additional transparency to your workflow can lead to a happier, more productive development team, a better relationship with your product owner, and higher quality software released to production.