Why Feature Briefs > Epics

In Agile Scrum methodology, an “Epic” is used to describe a feature that is too large in scope to be defined by a single user story. An Epic is a related group of Stories that comprise a product feature. In my experience, this defines most major features. Unless it’s a quick fix or bug, seldom are features comprised of a single user story. Epics are usually articulated by a one line description, and this is where the problem lies. Here is an example of an Epic and its children stories:

Epic 01: Provide ordering and priority options to user to manage backlog easily

• User Story 01: As a release manager, I want to have my releases mapped to different sprints. I also want to see the priority of each item on same board.
• User Story 02: As a system admin, I should be able to provide rights who can prioritize product backlog
• User Story 03: As a user I should be able to re-order my backlog using numbered items, star priority or simple drag n drop

There are many problems with reducing a feature down to a single line descriptor, but the biggest is that it presupposes the feature is worth doing. It provides no method for validating or even prioritizing the feature. If teams are arbitrarily pulling the next set of Epics from the backlog they are throwing features at the wall to see what sticks.

A Feature Brief (or PRD) is a more comprehensive representation of an Epic. While breaking requirements down into simple and easily comprehensible user stories is a highly effective practice, one needs to dig much deeper into the problem space and possible solutions to understand if the feature/epic is even worth building.

I encourage deviating from strict Agile Scrum practices and using Feature Briefs/PRDs as a canonical solution-oriented document defining, among other things, the user experience, business benefits, technical architecture, logic and implementation plans required to launch a Feature.

Feature Briefs evolve over the product development lifecycle. Initially they serve as a means of defining user problems, proposing a variety of solutions to address them, and information gathering until a single solution is selected, based on research and experiment results.

A product or feature brief is both the definition and evaluation of a potential solution to a user problem. It is written by a PM, with collaborative input from product design, engineering, data science, product marketing and other stakeholders. The author may or may not be the source of the idea being evaluated. It is a written document (not a presentation) and is the first formal articulation of a solution hypothesis.

UX research plays a pivotal role in designing and implementing the user studies to help evaluate (or invalidate) assumptions.

In essence a Feature Brief serves as the exit criteria for entering the engineering phase and building the feature.

Benefits

1. Articulates the problem and proposed solution in a way that anyone can understand, including non-technical stakeholders and teams
2. Determines the most viable solution through research, user studies and data analysis
3. Tests assumptions prior to writing production code, increasing the probability of success for those projects that pass the exit criteria

Following are the sections that should go into a feature brief:

1. User Journey
   Storytelling is a universally understood and highly effective way of capturing the essence of the solution and the use cases addressed. It also humanizes the feature, as the reader can picture how and under what circumstances it appears.
2. Problem
   What problems are we trying to solve or user pain points we’re seeking to alleviate?
3. User Stories / Use Cases
   What two or three core use cases do we believe should cover ~80% of users? What use cases have been identified as edge and why?
4. Customer Segments & Channels
   Who are we building this for and how will it be sold (if applicable)
5. Competitive Solutions
   What if any competitive solutions exist and why are they insufficient?
6. Rejected Solutions
   What other approaches did we consider and why were they rejected? Have market dynamics changed since their rejection? If so, in what ways, and how should those changing dynamics affect our approach to the problem, both in the short and long term?
7. Proposed Solution & Value Proposition
   A brief description of the proposed solution, including its unique value proposition.
8. Unique Advantages
   Why are we uniquely capable of solving this problem? What do we have that others don’t?
9. Revenue / Cost Structure and Projections
   How are we going to make money and how much? What will it cost to build, run, market and maintain this feature?
10. Go to Market Strategy
    How do we bring this product to market? What marketing tactics will be used? What’s the messaging and how will it be positioned?
11. Success Criteria
    How do we define success? Failure?
12. Risk factors
    What could go wrong and what is our plan to mitigate risk?