10 Practical Steps to Create a Product Backlog

Creating a product backlog for a substantially big product capability can be daunting. In my experience, the most difficult part is to figure out ‘where to start’, as not everything is clear at this stage, you may have so many contradictory thoughts, and breaking down that capability into digestible chunks seems like a challenge. Here is a path that I follow to create a backlog when —

• I have a strategic roadmap and have figured out the direction of travel.
• I have divided the roadmap into logical releases based on market feedback, user demand, business priorities.
• I have wireframes of key interactions/screens but may not have all screens thought through.

10 steps that will make backlog creation easy

1.Start with personas and workflows: I keep the main job to be done in mind and identify the different personas involved. I sketch the workflow that a user will follow for getting the job done. I usually do this for all personas involved. This helps me in identifying the different steps involved and various product functionalities needed to achieve a user goal.

2. Follow the workflow to break down capability into features: I use the documented workflow and identified functionalities to create feature backlog. I think feature and epic are used for the same purpose i.e. to group smaller requirements together, but the format of writing it changes. To me an epic is a term that is very specific to the scrum framework, while a feature is more generic. An example of what a feature looks like is “payment via PayPal”. While an example epic is, “as a customer on an e-commerce store, I want to buy a t-shirt and pay with my Paypal account so that I don’t have to enter my credit card information”. Both epic and feature can be broken down into further smaller requirements/user stories.

3. Start with short and simple bullet points for each feature: Once features are written down, I start writing their description including ‘why’ and ‘what’. It’s a good practice to write why you decided to develop this feature and what are specific user needs you are trying to solve. This always helps in re-stating user goals so the feature description is really focused on the core problem getting solved. I also try to include the metrics I plan to use for measuring the success of the feature. At this point, the details can be high level and it’s totally ok to not have everything ironed out.

4. Make working assumptions. Part of the challenge is that not everything is clear at this stage. I usually create some working assumptions and refine them as I get closer to the details. If there is a gap and I don’t know what is the correct path forward, I make an assumption and proceed. It has taken me some experience to be comfortable with assumptions, as I have realized that I can always come back to my feature list and refine it.

5. Collaborate early: Keeping the UX team close to your thinking process is crucial. Socialize with UX team on user journeys, product workflows, early wireframes, and refine them. It also helps a lot to talk to engineering teams early on. The general notion is that features and user stories should be from a user standpoint and may not require tech thinking, but I’ve learned that getting the engineering team’s perspective at an early stage could influence how a feature is conceptualized. It’s always good to factor in architectural limitations, opportunity to reuse any existing capability, option to plug and play with third party tools, etc. while defining a feature to avoid any re-work later.

6. Detail the features which are focused on the next few releases: Add details to the features, convert details to user stories and refine them based on your discussion with other teams. While adding details, I make a conscious effort to keep roadmap items and backlog separate and expand the features planned for next few releases. Items that you aren’t ready to dive into should be off the product backlog. I’ve had a lot of success keeping backlog manageable by keeping focused on items which are truly ready for the team to work on.

7. Add priority: Add relative priority of items. This is a highly strategic step and helps in stack ranking the backlog. Have a prioritization structure in place and use it to defend your prioritization decisions. You need to be able to present the structure, communicate it, and get an agreement on it later on. I usually use a simple yet effective ICE (impact, confidence and ease) method for adding relative priority. At this stage ‘ease’ score may not require a proper effort estimation from the team but could be your own judgment of how complex/simple a feature is.

8. Say NO: We have a hard time throwing away anything, especially good ideas. While adding features you’ll realize that you are adding items that were identified as an edge-case in customer research/interviews or features you’ve heard marketing teams talk about. I encourage being fairly ruthless in removing items from your product backlog. If you don’t think you’ll realistically ever do it, just get rid of it. Maybe keep a note of it somewhere else, so you remember why you removed it. But keep your backlog clean. I think the hardest part in managing the backlog is not to know what should go in, but deciding what should go out.

9. Create a canvas to make your backlog more visible: I ALWAYS create a board or a canvas that shows links between the capability, features, and user stories. You can use sticky notes, tables/charts, or sophisticated story mapping tools to plot this view. This view has many advantages 1) it’s easy to connect the dots and see how various features fit together 2) duplicate items and gaps get easier to locate 3) Time will not be lost in looking for items (“I know it’s in here somewhere”) 4) Adding/updating priority will be simpler.

10. Proactively refine and manage: Although mentioned in sequence, the above steps are cyclic. With every cycle, things will get more clear, you’ll get more confident with details and the backlog will start shaping up. Change is constant and responding to change is an important part of agile development. I have made it a habit to at least spend 30 mins each week to manage the backlog, add new items, remove duplicates, bump the priority up/down, remove ideas that are not validated.

Once I am confident with the backlog, I would start grooming sessions with engineering teams to add more granular details, break down stories into sub-tasks, add tech stories and acceptance criteria. The backlog doesn’t need to be 100% complete (it will never be!) to start grooming activities, you can start groomings with the team after you have enough confidence and have details of the highest priority features. The key is to start small, in fact, the key is to START :)