I recently wrote an article to explain how I describe user stories. Since I published that article, I’ve received a request for more information on feature refinement, so I thought I would describe how I approach that in a bit of detail.
What is a Feature
Before I dive in too deep it’s helpful to address three things when it comes to the use of the word feature.
- Have a shared understanding of what feature means to you and your team. Feature is used just as frequently as epic to represent big backlog items, and it can lead to epic confusion.
- Features represent outputs. They are things your team might deliver in order to help your customers or stakeholders realize a specific outcome. A backlog is more useful when the items you track are expressed in terms of the outcomes people can realize rather than the output that helps them do that. That is especially true for broader scope backlog items, which features are.
- Features are for customers; user stories are for the team. Although it was not the original intent of the user story, in practice, user stories have become small granular pieces of the overall output that often need to be combined with a few others to help customers, stakeholders, and users achieve their desired outcome. Items initially placed on a backlog based on discussions with customers tie directly to a particular outcome and are often called a feature or an epic (see point #1). They are then broken down into user stories to help the team organize their work in an incremental and iterative fashion.
With those three ideas in mind, think of a feature as an output that you think will help your customer achieve an outcome. User stories are small granular items that your team may deliver in order to deliver the broader feature, and ultimately help your customers achieve their desired outcome.
Throughout this article, I’ll use the example of revising the search functionality on agilealliance.org to demonstrate how I go about doing feature refinement. The outcomes we sought to influence were to: Make information on agilealliance.org easier to find in order to improve brand awareness and increase value to members. The items in bold italics are two of Agile Alliance’s value dials, which you can think of as organizational decision filters.
We determined that one of the things we could do to impact that was to improve the search capabilities of the site – primarily making the search results more relevant, and to make the user experience of the search results more intuitive.
Why do Feature Refinement
You can get a lot of value out of having big items on your backlog (ie features) because you can get a broad view of the overall output you might need to deliver without having to dive into detail on any one particular item too soon.
At some point, though you do need to dive into detail on something in order to start delivery. Feature refinement provides a way to do that in a way that allows you consider options and focus on the essential aspects of the feature and discard the aspects that aren’t completely necessary.
Who does Feature Refinement
Feature refinement is a team sport.
As product person (product manager, product owner, business analyst) you hold the vision of the outcome and guide the discussion to make sure the feature your team arrives at satisfies that outcome. You also bring an understanding of the business related constraints (primarily time and cost) to the discussion.
You need the perspectives of your customers/stakeholders/users to provide insight on their desired outcome and the context to identify what will make a solution valuable.
You need the perspectives of your team and their understanding of the available technology to identify solutions that are feasible and usable.
The Feature Refinement Cycle
Feature refinement starts with a feature and arrives at the right set of user stories through the use of design thinking, analysis, and conversations.
This description assumes that you have identified features that you believe will help your customers achieve their desired outcome and that you have determined that a particular feature is the next best thing to work on. A Technique such as impact mapping can help you identify features when you have an outcome to deliver but aren’t quite sure how to get to it.
Build Shared Understanding about the Feature
You choose to do a feature because you believe it will have an impact for your customer. It may not help them fully reach the outcome they desire, but it should certainly get them closer.
Make sure that your team understands what that desired outcome is going to be and agree that it’s possible to make that happen. You can usually accomplish that by discussing the metric you’re going to look at to gauge the success of the feature as you deliver it.
Establish some non-metric based acceptance criteria to use to gauge the success of the feature.
In the case of search on AgileAlliance.org we thought that improving the search functionality, we’d improve brand awareness and increase value to members. We reasoned that people would be able to find information on a specific topic quicker, thus making the site a more useful resource.
There are no metrics that we can look at to gauge whether our search result changes had a direct impact on those value dials, so we tend to look at the general trends in website traffic and specific behavior surrounding the search results pages to give us an indication of how the feature is performing.
To be honest with this particular example, we focused much more on non-metric based acceptance criteria that search results were more relevant (the expected result showed up first) and to improve the user experience of the search results.
Get a general agreement with respect to the output that will get you there. When you’re refine a feature, you are in effect starting discussions in earnest about your chosen solution. This is where collaborative modeling with mockups and process flows are very effective.
The team got together at the beginning of 2017 and discussed the issues we experienced with the search results, and also talked about the resource displays in general and how the content was organized on the site. The content was organized based on resource type – video, event session, book, blog post – instead of around topic. We determined based on feedback we received and examining other similar sites that organizing content around topic was a more intuitive route to go.
During the discussion we reasoned that combining the listing of resources and search results would address several of the issues on the site. We called the resulting feature Search, Filter, Order. Not the sexiest name, but we all understood what it meant.
Once we determined a general direction, we supplemented our discussion with a sketch on the whiteboard which gave us something to point to and reference:
Identify Options for Delivering the Feature
Using the collaborative model as a guide, identify all the things you could possibly do as part of that feature. You are using divergent thinking so try to keep the constraints fairly flexible (although to provide for a little bit of focus, keep the overall outcome in mind).
These options can be alternative approaches, and can also be the things that need to occur in order to make the feature happen. Note you’ve identified the general direction of the feature,
I’ve found it very helpful to have your model on a white board and identify all the things you could do to deliver it on sticky notes. Where possible placing those ideas on the appropriate part of the model to provide some context.
The options you identify are candidates for user stories, but you may find that some may end up being a bit too big and will need to be split, which you will start doing in the next step.
You may find Story Mapping helpful to identify options, especially if you are working on a full customer journey or trying to support a process.
With agilealliance.org search, the sketch of the result page was on a whiteboard and we used post it notes to note all of the items that were aspects of the search capability on post it notes. Sadly, we didn’t take any pictures of the white board in that state, although it would appear as though a Sticky Note factory blew up in the room.
The notes included a variety of things we’d like to do with search, many of which were influenced by what we had sketched on the whiteboard, such as the ability to filter results by a variety of attributes, the ability to change the order of the displayed results, the ability to like certain items, and save items, and pagination for the display.
At this point, the sky was the limit, as long as the item was relevant to helping people search for a specific resource on agilealliance.org.
Converge on the Options That Produce a Valuable, Usable, and Feasible Feature
This requires convergent thinking to toss out the options that don’t directly relate to achieving your desired outcome and identify those things that are necessary for the solution to work.
At this point you stop brainstorming and take a look at the options you have. Some things you may do at this point:
- Cut out the options you come up with that exceed one of your known constraints
- Identify the items that are missing and are necessary to deliver the feature, such as infrastructure and implementation items.
- Reorganize the items that represent different options for the feature. These are things that the feature could do, but may not be required right away, or at all.
Some techniques that you may find helpful for this discussion are example mapping and story splitting. These techniques are typically used when you are refining user stories, but the structure and some of the ideas contained in these approaches can also be helpful when you refine a feature. Both of these techniques put the team in the frame of mind for breaking the feature down into smaller chunks that add some sort of value to your customer. You may not get the items down to an appropriate size that can be delivered in an iteration, but you can at least get them into chunks that allow you to consider which ones you want to deliver in which order.
For search on agilealliance.org, we threw out some things such as liking content, or saving content to a dashboard because we knew those items were beyond what we wanted to accomplish with this particular feature.
The team identified some infrastructure work, such as selecting an indexing mechanism, and the work necessary to integrate the new search functionality into WordPress. The team also included backlog items for the transition work to replace the existing resource listings with the newly built search results listings, which would serve double duty as a resource listing.
To help us pick and choose which options we may implement and to give us some items to work with when selecting our first delivery, we split the broad concepts such as filtering into smaller items. The resulting user stories that we derived from filter were:
- Filter results by type
- Filter results by topic
- Filter by event
- Filter by initiative
- Admin can select Taxonomies and their values to allow users to filter by
Again, these terms may not be completely clear to you. The team did have a shared understanding of what these terms mean in our context, so they acted as good placeholders. As it turned out, most of these items were of the appropriate size and were not split down any further, but they may have as the team started digging into a particular item.
If you would like a reference to the twenty-one most common story splitting patterns along with examples for each, sign up for a free membership to kbp.media. You’ll get access to the Story Splitting Patterns as well as other resources such as a handy guide to Backlog Item Types and the ebook Product Ownership in the Wild. You’ll also get access to additional resources as we add them.
Prioritize and Select your (First) Delivery
Once you have a collection of items that your team feels adequately covers what you want to deliver with your feature, you then need to identify the subset of the items you want to deliver first (or next).
At this point, you have an interesting decision to make regarding prioritization. You could say that you’d like the team to size all of the items related to that feature to help you prioritize, or you may decide to do an initial prioritization to indicate which items you’d like to have the team size first. It all comes down to what type of decisions you need to make and what information you feel you need to make those decisions.
You’ll generally find that you have a certain set of items you know you have to do in order to have a usable feature. Then there are going to be other items that when added may provide some value, but that value may not outweigh the cost of delivering them.
It’s also at this point that you need to decide whether to deliver in order to learn (an MVP approach) or deliver in order to earn (an MMF approach). The approach you chose dictates to some extent the items you include in the first delivery.
Whatever you choose, make sure you can have the quickest feedback cycle possible, so that you are positioned to deliver something, get feedback, and adjust, which is the next step.
When we were worked on search for agilealliance.org, I prioritized the items and put them into three groups – A, B, and C based on Todd Little’s approach to prioritizing backlogs.:
- Group A: MUST be completed in order to ship the product. You will change schedule if necessary to make this commitment.
- Group B: WISHED to be completed in order to ship the product, but may be dropped without consequence.
- Group C: NOT TARGETED to be completed prior to shipping, but might make it if time allows.
Group A included the infrastructure items and implementation items as well as base functionality that if it wasn’t there, search would be pointless.
Group B included some of the variations on filtering, as well as “nice to haves” in the result displays.
Group C included everything else that made the valuable, usable, and feasible cut.
The team started by sizing items in Group A and Group B, and some of the Group C items if they had time. I mainly needed that information to determine how much we could get done within the allocated budget and to determine whether I needed to ask for more budget in order to produce specific capabilities.
As the stories started getting sized, it became apparent that we’d have some tough decisions to make. The Search Filter Order addressed Resource Grid and search issues, but there was a lot that has to happen in order to make it work and that meant we wouldn’t be able to deliver everything I’d originally put into Group A at our current budget.
I printed all the items out so I could sort things and see what groupings would work. I took the approach of scaling back our expected outcome. I placed the Group A items that were needed to replace search functionality in one group (you can think of it as A1) and the items needed to display resources and search results in the same way as a separate group (A2).
Organizing the items this way was beneficial in a couple of ways. First, I was able to identify the items that should be included in the first delivery regardless of whether we got additional budget. That was the A1 group. Second, I was able to put together a cohesive feature with the A2 items that allowed me to guess at a size and identify a discernable value from those items.
Deliver, Reflect, and Adapt
At this point, you have a set of items that you can feed into your team’s normal discovery and delivery process. The items may be properly sized user stories already, or you may need to split of them down even further.
You’ll also describe the user stories and build the resulting functionality, delivering to your customers/stakeholders/users once you have a valuable and usable set of functionality.
Gather feedback on the delivery and use that feedback to determine what aspects of the feature you release next.
Along the way, some of your “deliveries” may be internal to your team if you are trying to figure out some technical items, or they may be MVP type work that you use to answer some questions or verify some assumptions.
At each delivery have an honest, frank discussion around whether you’ve delivered the promise of the feature and whether you need to keep going or if you are truly done.
If you think you still need to deliver more items for the feature or the feedback tells you as much, you’ll revisit the Prioritize and Select your Delivery step to determine what you should work on next.
If you think you are done, you’ll select a new outcome to deliver and circle back to Build Shared Understanding about the Feature.
The main question we had was the search mechanism that we were going to use. We weren’t happy with the results that the built in WordPress search functionality gave us, so we explored the other available options to pick one that suited our needs, primarily that we are able to influence relevancy with some rules. A key rule is relevancy based on the type of resource. For example, if you searched agilealliance.org for backlog grooming the first result we’d expect to come back is the Backlog Grooming glossary item. (Yes… I know that “grooming” is not the favored word anymore, but many people still look for it in using those terms. The glossary item does make the point that it is more properly called backlog refinement.)
The team did some research on various search indexing mechanisms and then piloted a couple of them. We didn’t release this functionality to the wild because the main question we were trying to answer was whether we could influence the relevancy of the results.
Once we selected our desired search indexing mechanism, we started working on the items (Group A1) to build out the search capabilities. By this time, we were also able to secure some additional budget so we could also complete the display resources (Group A2) and search results items.
As we progressed, we were fortunate enough to discover some efficiencies that allowed us to get rid of some items because we were able to address them via work in previous items, which allowed us to build some additional features. Along the way, I reviewed the functionality built to date and provided the team feedback that they incorporated in their subsequent work.
Once we felt we had a usable solution that provided a bit of value, we started implementing it on the site. We switched the site wide search over to the new search solution, and slowly started replacing our current resource display with the new functionality. Along the way the team continued to add additional functionality, which by this time were some additional capabilities that were not essential to the solution, but did provide added value.
We were quite pleased with the end result and all indications are is that it has improved visitors and members abilities to find resources on agilealliance.org.
In case you haven’t had a chance to use the site search, here’s what it looks like:
When do you do Feature Refinement
Don’t think of feature refinement as a scheduled meeting. It’s an ongoing activity where parts may be done as a specific event, and other aspects occur throughout the course of working on a product.
You may find yourself doing some aspects of feature refinement on an ongoing basis, but different steps in the cycle are more prevalent at certain times than others.
When you are preparing for a release, or getting started on a new product is when you will typically go through these steps:
- Build shared understanding about the feature
- Identify options for delivering the feature
- Converge on options that produce a valuable, usable, and feasible feature
Then you’ll get into a smaller cycle within the larger one where you iterate between
- Prioritize and select your delivery
- Deliver, reflect and adapt.
During those iterations you will most likely identify new options for delivering the feature based on feedback and remove some of the items you had identified before. That’s natural, expected, and a good thing.
Once you deliver a feature that properly satisfies the desired outcome, you then circle back to identify a new outcome and a new feature and start the whole cycle over again.
If You Remember Nothing Else
The important things to remember about feature refinement are:
- A feature is an output that you think will help your customer achieve an outcome.
- Features give you a broad view of your solution and help you to determine where to focus each specific deep dive.
- Feature refinement is a team sport.
- Feature refinement starts with a feature and arrives at the right set of user stories through the use of design thinking, analysis, and conversations.
- Feature refinement is an ongoing activity
How Do you Refine Features?
This is a description of how I typically refine features. I realize it may not be the same way that everyone approaches. I’d love to hear how you go about doing it, so please share in the comments below.
And if you have questions about what I’ve described, feel free to ask those as well.