Back to Forum

Steps to manage Product Backlog

Last post 05:50 am August 19, 2016 by Puja Kalra
No replies yet
Puja Kalra
05:50 am August 19, 2016

As a Product Owner, do you have the fear of providing proper User Stories to the teams at the end of every Sprint?

You can arrive in this situation quite easily in case you are working with more than one team/scrum on the same Product Backlog. And the User Stories are not defined properly or you could say lack of quality User Stories to be worked upon during the Sprint. Key to success here is the focused and constant grooming of the Backlog. But the question here is:

How to prepare the Product Backlog?

You can come across various blogs/White Papers which covers the characteristics of good Product Backlog but does not cover the How part. Here I tried to cover how to manage the Product Backlog step-wise as per my experiences in the role of Product Owner.

Here you go -

A Product Backlog is a prioritized set of work which includes new features for the market, technical debt to improve the Product quality, customer requests, and scalability and engineering work for the sustenance. Each Product should have only one Backlog maintained which should be prioritized and continuously evolving. At any point of time it is important for the Product Owner to have a clear picture on what is the priority item in the Product Backlog.

Key Points to Manage Product Backlog are:

• Step 1 - Structuring Product Backlog - There are numerous techniques that can be followed to structure the Product Backlog in Agile based on the type of the Product you are working upon. You can define a Portfolio that can span across multiple Software Releases or can create a one for a single Release. Few of the techniques are:

• "FIT" Topology, this approach is suitable when your Backlog span across multiple Software Releases. It involves breaking your requirements in following structure, Theme > Initiative > Feature e.g. Theme could be 'Security' covering all security specific work planned for the Product which in turn can have multiple Initiatives one such example could be 'Compliance for FIPS' and then the Features which can further breakdown such as ' Strong cipher support'. A feature can have various User Stories that can be executed by Scrum teams.

• "Epic Feature" Topology, this is simpler and effective in case you are maintaining Backlog Release wise. Smaller similar features can be clubbed together under an Epic e.g. symmetric customer requests can make an Epic which can have multiple features. Feature again need to be breakup in User Stories.

• Step 2 - Product Backlog Grooming - Once you have structured the Product Backlog, it’s time to groom the Backlog. You can categories the Backlog in various categories varying from 20% -> 50% -> 80%.
• 20% (Product Owner freezes the requirements from customer and create Epic & Features)

• 50% (grooming with System Architects and breaking the features into User Stories, try to slice the User Stories in a way that can be deliverable)

• 80% (detailed grooming and ready to consume by team. Output should be quality User Stories with well-defined acceptance criteria)

Note - Regular Product Backlog grooming sessions are required; it should be focused and should have target audience.

• Step 3 - Sizing with common team - Once you have Product Backlog ready; not necessarily all features at 80% grooming level. If you have 3 Sprints content ready for the team, you can go ahead for the common sizing with the developers for those User Stories which are ready for the consumption. Key benefit of common sizing are:

• It increases competition if you have multiple scrums. As a Product Owner you can utilize this competition in terms of effective and balanced User Story sizing.

• Conversation between Product Owners and the development team bridges gaps related to requirements.

Keep asking you below questions:

Here are the set of questions which you keep on asking yourself to ensure you are on right track:

• Do I have a single and correct copy of Product Backlog which is agreement with all stakeholders?
• Do I have a priority for each User Stories defined in the Backlog?
• Do I have enough User Stories for next 3 Sprints?
• Are the User Stories Ready, have proper acceptance criteria (the what, not the how)?
• Do I have a regular Backlog grooming meeting scheduled and attended by all stakeholders?
• What is the current Sprint velocity? This will indirectly give how much you should keep in pipeline in the way of Sprint-sized stories.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.