Feature breakdown documents
Business analysts, product managers and product owners usually work a few sprints or weeks ahead of the team to define the mechanics of certain features or system capabilities. Feature breakdown documents are a great tool to align the team on all aspects of implementation - from the business context to the details. Fear not - this isn’t a long system requirement specification from the days of yore. Effective feature breakdown docs are brief and help connect various artefacts. They don’t serve as product documentation. Instead, they’re a reference for the development team. Here’s what I include in my feature docs.
Business context and success metrics, if any.
A brief explanation of how it’ll work.
Links to any of the applicable artefacts.
Research about end users and feedback, if any.
Mockups, wireframes, or clickable prototypes.
User stories and epics that this feature relates to.
A list of frequently asked questions. You can create this as you get reactions from people.
Confluence, Notion, and other tools have built in templates to help you write your feature documents. The reason feature documents are powerful is that you can enrich them as you go. Often, we build the minimal version of a feature and wait for feedback to enhance it. When you get that feedback, guess where you link it up? The feature doc! What about new user stories - where do you reference them? Course, the feature doc. How about known issues? No brainer, eh? Use them well, and the document can be a powerful, single source of truth to describe the lifecycle of a feature or system capability.
