Are you struggling with tracking work through your system? Finding it difficult to get the “big picture” view of how complete a feature is? Wrestling with thin vertical slicing and evolving it? Are you lost in a sea of ticket numbers not sure how Story #NJ-348 fits into the November Release? Maybe you are longing for the simpler days of sticky notes on a wall but constrained by needing to track work while remote. Fear not, friends and I have developed and evolved a great work tracking and focus technique that we call a Discovery Tree.
Discovery Trees are a very Agile way to track work. It’s highly effective, flexible, and delivers incredible visibility. We initially iterated on it with post-its on windows, walls and whiteboards, but we’ve evolved it to work online with tools like Mural and Miro. My example below is using Mural. The process in this example will leverage evolutionary design, thin vertical slices, and outside-in (London Style) development. Your company’s process can and might integrate differently with Discovery Trees as they are very flexible. As you read this example, rather than focusing on the mechanics of Discovery Trees, focus on the mindset and philosophy.
You have a story representing a piece of user value, and you’re discussing work to be done. You create a Mural board and add one 3x5 Note with only a little detail.
It’s quick and simple to start. The team has decided that this is the highest priority thing that needs to be worked on. The next step is to get together and have a conversation with all the right people and start to build the tree.
It’s a straightforward task. Build an API that will receive some JSON and save it. It takes less than 15 minutes to get the above clarification/work breakdown. Get used to impromptu discussions like these because you’ll have a lot of them—that’s part of being Agile. Frequent 2–10 minute discussions can save hours of upfront meetings, and days worth of time spent working on things you don’t need.
This is enough for us to start working. The developers get together and start writing code.
The key underlying concept evolving the discovery tree is to make things easily visible without needing context. We asked ourselves, “How can we improve this as an “information radiator” from afar and up close?” We track work on the board by changing the colors of the notes. When we were working in person by convention we rotated them 45°.
Two things are highlighted here:
- Task size doesn’t really matter. It’s about what’s needed by the team to keep track of things that need to be done. As tasks get bigger, they tend to get more sub-tasks under them. We had tasks/subtasks that could take as little as 5 minutes (but were important enough to deserve a Note) or as long as a day. It’s about what’s useful for the team to convey information inwards (hands on keyboard) or outward (hands not on keyboard). The discovery tree is a place to put thoughts and placeholders of things that come up, things you might need, and other musings.
- A new discovery! We frequently discover new requirements when doing Just-in-time planning and evolutionary design. Discovery Trees embrace that change by growing the tree. Here you can see we added a newly discovered requirement, tasked it out and are working on it.
Another theme for us to consider about the Discovery Tree is that it’s there to help keep the team focused on the task at hand. If something comes up distracting the team, put it on the board! Doing so will “bookmark” the distraction and allow the team to keep focused on their task.
Work progresses and the tree continues to grow. It’s pretty easy to see, even from a high level, what’s been done, what’s being worked on, and what’s still to do. Discovery Trees are a simple concept that are very adaptable that excel as information radiators. Being able to look at them quickly to see what’s been done, what’s being worked on, and what’s been planned out is quick and easy. The simple addition of a red card can be used to draw attention to work that is blocked.
Overall I try to keep colors to a minimum: work to do, work in progress, work done, and blocked work.
Some places where I’ve introduced this practice there have been requirements to show who’s working on things and how to track them in work tracking software. I’m not going to go into the merits of doing these things vs. not and like those times, I’ll just accept that sometimes you have to. In those cases we modified the structure a little and created name tags to denote who’s working on things (whiteboard magnets with names!). When task numbers were required we did the extra work: added each task into the task tracker, kept them updated in the tool, and closed them out when done. Your environment might not require these things, but might have other demands. When a question surfaces more than a couple times, can you find a way to integrate the answers into the discovery tree so people can self-serve the answers?
Discovery Trees really highlight Agile values and principles. It leans into individuals and interactions while providing the minimum of process and tools. The whole tree evolves and responds to the ever changing landscape that is software development. It embraces changing requirements for the customer’s competitive advantage. When practiced well it simplifies and helps to maximize the art of work not done.
If you are more familiar with Extreme Programming and code craft, Discovery Trees can help take things to 11. It’s a simple and amazing information radiator for everyone working on the project. It embraces the chaos of software development and really harnesses the power of evolutionary architecture, if you let it. When done right, it delays planning until the last responsible moment freeing up work updating stories and tasks as things change. You can leverage delivery of thin vertical slices to inform your development too. Making those slices visible can facilitate discussions like, “Is this good enough?” and “What’s the smallest chunk we can deliver to start getting feedback?” together as a group, not just having requirements thrown over the wall and demoed months later. It changes the conversation from disparate bits of work to looking at features as a whole. How can we get the feature done, instead of just components of the feature?
For a story, Discovery Trees are a great way to convey information and show the state of that story. For me, and for teams I’ve introduced this to, it has one very surprising effect: It helps individuals and teams to focus.
Related Discussion:
We had an open discussion through our Industrial Logic TwitterSpace. Here is the recording of that conversation.
