Being a PM is not a piece of cake. You probably know that by now. You have probably also encountered a long list of features hanging in the air, unsure why half of these features were on that list in the first place. This is exactly why brief discovery projects are important in figuring out whether it’s worth developing a feature before going into the details of how to develop it at all.
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 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.
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 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.
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.
It is not uncommon that teams disagree. In this article I’m not going to talk about how to avoid these situations, instead, I’ll focus on how to proceed once a discussion has reached a deadlock.
Focus on decisions, not on discussions
Discussions can go on and on until a person gives up. This is not what you generally want to happen. You should rather turn the never-ending discussion into a decision to be made, with a number of options to choose from.
Understand where they stand
Ask your team members to add arguments for the different options. But also ask them how important the arguments are. Collective decision making is about gathering opinions and views.
Suggest a decision
It needs to boil down to a decision. So go ahead and suggest one. Then go back to your team and tell them what you suggest, and the rationale for it. You will be amazed how easily your team will accept your decision. And for a single and simple reason. You have listened to them! Their opinions are taken into account, even though the outcome is not exactly what they hoped for.
What if it backfires?
Of course, there is a chance for failure. Someone really doesn’t like your decision. Then ask that person, is it something I have missed or do we value a certain argument differently? Once you have identified the difference in reasoning, make it explicit. e.g. “I think I value smaller and faster releases very high, while you see a value in major releases for PR purposes.” And then go ahead with your decision.
Remember, collective decision making is about gathering opinions and views and not about unanimous decisions. The final say can still be up to a single child. A consensus is not needed!
We all have opinions. And when our opinions are not taken into account we felt not only personally ignored, but also that the company is missing out. But from the employers perspective, what is really an opinion. And when does it make sense to take it into account?
Taking an opinion into account has two potential benefits, insight and involvement. The benefit of the insight varies from basically zero to potentially very large, depending on what decision is being made, and how relevant the insight is. The involvement benefit of taking the opinion into account varies a bit less and depends mostly on how strong the opinion is, and to be frank, also on who holds the opinion. Not taking an opinion strongly held by a key team member into account can have quite a negative impact, and then the benefit of taking it into account is significant.
But taking an opinion into account also has a cost, mainly in the form of time and focus. To take an opinion into account, three things have to happen: it has to be captured, incorporated, and replayed. Capturing of opinions happen either from noting what someone states without being prompted, but often times it requires asking. Incorporating the opinion means thinking through, in a structured way, how it affects the decision being made. Once an opinion is incorporated, it can be replayed to the person who gave it. Replaying an opinion isn’t strictly necessary to take it into account, but without some kind of replay, most of the benefit from involvement goes to waste.
As you can see from this reasoning, taking opinions into account can really be seen as a cost/benefit calculation. So, if it is cumbersome enough to capture and incorporate opinions, it actually makes sense for a company to disregard many opinions. And that pretty much explains why most companies do.
But that then begs the question:
What if it was possible to reduce the cost of taking opinions into account?
That is precisely what we have been working on at Delibr. Our tool allows you to capture opinions in a structured format. It shows what people think, and based on what rationale, and makes it easy to get an overview of the discussion. Our mission is to reduce the friction that comes as more people are involved in making a decision.
As we have seen, if the cost of taking opinions into account were much lower, many more opinions would be taken into account, and that would give companies both better insights and more involvement.
The six thinking hats is an excellent framework by Edward de Bono for having discussions that are more structured and balanced.
The idea is that all thoughts and statements can be put in one of six categories. As a pedagogical device, the categories are represented by six hats.
Blue hat – The Big Picture – Thinking about thinking, where are we on the agenda, what questions should we discuss?
White hat – Facts & Information – Identifying and presenting information that is needed, what do we need to know to have an informed discussion?
Green hat – Alternatives and creativity – Coming up with ideas for answers to the questions posed, what if we do it like this?
Black hat – Critical Judgement – Highlighting problems and risks, coming up with cons for different options
Yellow hat – Positive Judgement – Emphasizing upsides and benefits, the good things, coming up with pros for different options
Red hat – Feelings & Intuition – Gut instinct on what to do, either in the early phase of the discussion or later on taking pros and cons into account, what option do you think is the best?
Most discussions benefit from having a facilitator that adds direction regarding what hat the participants should put on.
- If one option seems too good to be true, the facilitator can say “let’s put on the black hat, what are the problems or risks with this option?”
- If it seems the team is stuck with two bad options, the facilitator can say “let’s put on the green hat, are there any other options here?”
- If it is not clear what it is the team are discussing, the facilitator can say “let’s put on the blue hat, what is the question we are trying to answer here?”
- And so on…
Adding structure, balance, and direction to a discussion can be incredibly powerful, and allow the team to make better decisions, in less time, while still having a high degree of involvement.
But this is a hard thing to do, especially as soon as the group grows beyond 2-3 people. Even for an experienced facilitator, it can be hard, e.g., to tune into whether someone in the group is sitting on a killer pro/con argument or an alternative solution that for some reason is not coming into light.
The mission of Delibr is
to reduce the friction that comes as more people are involved in making a decision
We have explicitly designed the entire tool with the six thinking hats in mind to support this kind of facilitation and make it easier and more effective. All the concepts of the app map directly to the six thinking hats, as per below
- Questions – Blue hat
- Comments – White hat
- Options – Green hat
- Pros – Yellow hat
- Cons – Black hat
- Ratings – Red hat
Because of this, participants are naturally encouraged to engage with all hats, which makes the facilitator role easier. Especially for a team that has used Delibr a couple of times, this can be incredibly effective.