You’re starting work on a new a product or making some substantial changes to your product. You understand why you’re doing the effort and how you’re going to measure success. Now it’s time to identify what you need to do to make that outcome come to fruition.
You need to build your backlog.
Remember that when you build your backlog, the items on it are options not requirements. An item on your backlog could be done to deliver your desired outcome, it doesn’t have to be done.
You identify things that you think may help you get the outcome you’re looking for, but as you start delivering things from your backlog you’re going to learn that some of those other items aren’t needed, and that you may be missing a few things.
That doesn’t mean you should not put much thought into building your backlog in the first place. Sure you could get your team and stakeholders together and just brainstorm a bunch of items, but you run the risk of creating a wish list that doesn’t create a viable solution.
Here is a set of resources you can use to establish the big picture of your initiative and make sure the items you add to your backlog are well aligned to getting to your outcome.
How agile business analysts define scope
This is the fourth in a series of posts that take a look at the agile business analyst in terms of Laura Brandenburg’s 8 step business analysis process. This post takes a look at the step of defining scope and how that changes in an agile environment. The key ideas are that you want to make commitments based on outcomes, not delivering a specific scope, and your backlog represents a view of your understanding of scope at that point in time.
If you know the outcome you want to reach, but aren’t sure where to start, you may find impact mapping helpful. You can use impact mapping to discuss assumptions, align with organizational objectives and deliver only the things that lead directly to delivering outcomes.
When the work you’re doing is intended to support a new business process or changes to an existing business process, you may find the best place to start building your backlog is to create a process model. This technique brief introduces process models, describes when they are helpful and explains how use them to understand a process and build a backlog.
Story mapping is the fashionable technique that is mentioned most often when people talk about identifying backlog items. It’s not an end all be all, but it can be a helpful elicitation technique when trying to understand a solution that has a great deal of user interaction. Creating the story map guides the team as they talk through the business process, identify the key activities, and lay them out in a logical sequence.
Feature Injection clarified (hopefully)
The act of starting with your desired outcome and figuring out your backlog items does have a name – Feature Injection. It’s an approach where teams understand the value an initiative intends to deliver, deliver the features that provide that value, and build a shared understanding about those features primarily through examples.