What A Beautiful Tree

There are a lot of things that go into building a software system.

You need to have a high-level vision to orient the whole thing, describing a coherent picture of the future in which the underlying problem is solved, or underlying opportunity exploited.

You also need a technical roadmap that sketches out the plan to make that vision a reality. It probably consists of some high-level capabilities, some technical components and how those two things intersect from a delivery perspective.

Probably most importantly, you need a group of engineers who are actively working from the roadmap, executing and delivering the necessary things.

That's it though, right?

Wrong.

Such An Impressive Landmark

Even if you have a vision, a technical roadmap and a delivery team actively executing on the roadmap, there is at least one major thing still missing.

Something that clearly describes what the system actually needs to do.

The technical roadmap partially deals with this problem, but it is very focused on high-level capabilities, architecture and project delivery. Good for alignment and for getting an overview of the situation, but that's about it.

It doesn't get into the nitty gritty details, like how a user is specifically going to interact with a low-level capability in the system and how that sort of interaction rolls up to the high-level capabilities that the system espouses.

Leaving the low-level capability definition up to the delivery teams is an option, but that road is fraught with danger. Different people executing different projects will likely have different understandings of what the system needs to do, even in the face of a consistent and well aligned high-level direction.

It gets worse when you go further out, into the set of extended stakeholders. The vision and technical roadmap might be enough for those with a passing interest, but for the people who need to understand the details, who have to justify the benefit being delivered from the investment, it's not enough.

Just like the people implementing, they need to have a clear understanding of what is actually going to be delivered, ideally without requiring them to read through hundreds and hundreds of individual delivery tickets.

So why not try a feature tree?

You Can See It From Everywhere

A feature tree is a representation of the functionality that your system needs to provide, written from the perspective of people who want to use it.

It focuses entirely on what system needs to do and shows clearly all of the required behaviour, from the largest and most involved workflows that need to be supported all the way down to the smallest and more straightforward.

An easy way to think of it is as a big old set of user stories, with relationships between those stories clearly noted in order to show dependencies.

One of the best ways to think about a feature tree is in terms of what it is not.

It is not a technical reference. Architectural components, technical considerations and other related concerns should not be included directly in the feature tree.

It's also not a roadmap. Project definitions, timelines or assigned teams should also not be included directly in the feature tree.

Those things still need to exist, they just shouldn't exist in the feature tree. Their source of truth should lie elsewhere, in an artefact that is fit for purpose, because if you try to put everything together in one place, it will become a completely unintelligible mess that provides no benefit to any stakeholder.

Note that everything (i.e. technical stuff, roadmap stuff and feature stuff) needs to be linked together in some way though. Each one of those artefacts can't exist in isolation, or you risk fragmenting the understanding completely.

The technical people need to understand what they are building and the stakeholders who care about functionality need to at least be able to follow a trail down to the implementation details as necessary for example.

Of course, knowing what a feature tree is, is only half the battle.

Knowing where to put it is the other half.

It's A Great Navigational Aid

Unsurprisingly I have thoughts about that. Half-formed thoughts, but thoughts all the same.

The first thought I had was to use Jira Product Discovery (JPD).

I've used the tool to capture the project backlog for a department of about 40 engineers or so, and I've also used it to represent the technical backlog for a large initiative that I'm responsible for running.

I'm pretty fond of it.

I played around with the free version to create a simple mock-up of what a feature tree could look like below:

The atomic unit that it operates in is stories, and the view above was created by having a field called Capability that the view is grouped by, allowing a single-level hierarchical representation.

The great thing about JPD is that it's flexible, so you can add all sorts of additional meta information to each item, and then create views that use that information to show the feature tree in different ways.

Because it's just Jira under the hood, you can also link things with other things in the same project and across projects as well, so you can clearly define relationships between items and to the projects that will be delivering them.

There are two downsides though:

• You can only have a single level of hierarchy. No multi-level relationships here, so it's a kind of squat tree
• There is no easy way to view dependencies. You can definitely set up relationships between the lowest level items (the stories) and pretty much everything else, but there is no view that shows those relationships visually. At least not as far as I know

The second thought I had was to use some sort of graphical representation, like a mind map.

There are any number of tools that can be used to create a visual representation of something, but because I work at Atlassian the first experiment I tried was Confluence Whiteboards. Miro would probably also work, Whiteboards was just easier to experiment with.

It's great at communicating relationships. As you can see, I've already easily got multiple levels of hierarchy, showing that the Observability capability relies on a specific story, which in turn relies on a bunch of fundamental features.

It also has a feature where you can sync items on the whiteboard with Jira. I know this because I've seen other people use it before, but I didn't get a chance to try it myself to understand how useful it would be in this context.

Without that, the whiteboard representation is great for communication, but would probably be difficult to correlate with the other artefacts (like the technical roadmap), relying on soft links instead.

I'm confident that there are many other ways to represent a feature tree, but those are the two that I experimented with.

Shame That It's Probably A Parasite

In case it wasn't obvious, I haven't actually created a feature tree for real yet.

It was an idea that a colleague of mine mentioned, and I thought it was a good one, so as is common with these sorts of things, I decided to use a blog post to explore it in more detail.

I'm definitely in a situation where I could use one though.

One of the initiatives that I'm running is struggling a little bit. The execution is going okay, but not great, but more importantly the extended stakeholders are having a hard time understanding what the resulting software system is actually going to do.

Creating a feature tree should help with that.

I hope.