Not Writing a Feature Refinement Document Can Lead to Chaos

You probably know all about roadmaps and user story mapping in agile product management. Both are effective tools used to capture and communicate your product’s goals and the journey to achieve them. User story mapping, for instance, will help to prioritize among relevant features and user stories and give the development team a better understanding of what to focus on.

However, what neither roadmaps and user story maps have, are feature details. These are never detailed enough for the development team to understand what has to be done just by looking at either a product roadmap or its user story map. And they shouldn't be too detailed. This is where the need for a separate feature refinement document comes into play. And for good reasons. 

The Three C’s in User Story Mapping

Before discussing the benefits of feature refinement documents, let’s have a look at some important aspects of user story mapping. According to Ron Jeffries, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto, user story maps have three critical aspects: Card, Conversation and Confirmation.

Card

Card refers to the user story, as user stories are sometimes written on index cards The cards are not supposed to contain all the information about a feature, just enough text to identify it. It represents the feature and has notes on it that illustrate priority and cost. 

Conversation

This refers to all communication among the stakeholders and the development team. Thoughts, opinions, and feelings are all part of the conversation. These are usually exchanged verbally, but could be recorded for future convenience. 

Confirmation

Confirmation refers to the set of acceptance tests that must be passed for the feature to be considered completed. An acceptance test is used to ensure the feature matches the customer requirements and has been implemented correctly.   

Feature Refinement Documents for Effective Conversation

The major chunk of the feature development journey falls between the Card (the starting point) and the Confirmation (the finish line). Feature refinement documents can make this journey run smoother, and here is why.

Coming back to Conversation, there are several communication channels that could capture it: whiteboards and presentations for live meetings, email, Slack, Jira (especially comments). However, it is usually not possible to have everyone updated on everything, as that would require everyone to be on the same communication channel at all times. People miss meetings, emails and messages. Sometimes missing the tiniest detail can lead to chaos.

The developers might not understand what is needed, the team communication might end up disrupted, and then the whole plan is delayed. Not the best situation, especially if the release date is getting closer. This is why a single document that contains all this information (in a well-organized, easy-to-navigate and readable format) is so useful.

When You Don’t Need a Document

There are two cases where there is no need for a feature refinement document in product management. One case is when everybody that will have an input in implementing the feature in question is present during the whole Conversation. In other words, they don’t need the updates and additional explanations, because they were present.

Another case is when there is a self-contained issue, such as clear-cut bugs or obvious design improvements. In all other cases a feature refinement document is useful to put the disconnected conversation back together.

Issues That Will Pop Out if You’re Not Using a Document

One of the possible issues to occur if you don’t use an agile feature refinement document are disconnected conversations. Going back to several communication channels mentioned above, it is often almost impossible to keep everyone updated and on track on different platforms at the same time. This is especially true when working with a large team. Disconnected conversations can lead to chaos, putting a halt to the development process.

Another issue that could do this is missed details. Neither backlogs nor user story maps or roadmaps can capture small details effectively. Backlogs often look overwhelming, while user story maps and roadmaps don’t cover all the small details about the features. In both cases the details can be difficult to navigate to, and to associate with the right feature. 

Pitfalls to Avoid

However, writing a feature refinement document is not a magic pill. There are pitfalls. The PM needs to capture lots of information. Yet that information is only useful if it is easy to access and navigate, which requires good structure. Sometimes, structuring the document properly requires more time than the PM has available. Then there is a risk that the document grows unwieldy and hard both to read and to work with.

When that happens, the agile document risks becoming obsolete, not used in practice. And having a document that nobody uses is as bad as not having a document at all. Sometimes it is worse even, as the time to create it has been wasted and people may not have realized that the document can not be relied upon.

Why Delibr?

Most teams already write some sort of feature refinement document. Writing it in Google Docs is the most common, which is better than not writing a document at all. But the teams that start writing these documents in Delibr find that they need to spend less time to get to a good structure. This is because Delibr is an outliner.

Outliners were originally used for writing books and movie scripts. In an outliner, the whole document is represented by a bullets tree structure. This gives outliners two main benefits. First, choosing what to see by zooming into or collapsing parts of the document is much faster. It allows for both seeing the hierarchy of the whole document and focusing in on a small part. Second, all operations related to moving content around are much faster and require no formatting effort.

Maintaining the structure of feature refinement documents might seem unnecessary and time consuming for you as a PM. However, the results are worth it, especially if you use an outliner to be able to do it with much less time. As a PM, you can avoid chaos by being writing better feature refinement documents. We aim to make this less painful. Work smarter, not harder.