Keep it simple, stupid: 7 simple yet effective ways to manage a product backlog

Product backlog

Product Backlog: the keystone of an agile project

As described in the Scrum Guide, “the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any change to be made to the product.”  In simple terms, it is the keystone or foundation of a product since it provides a centralized and accessible structure of what to build and the order in which it is to be built. The most important items also called Product Backlog Items (PBIs) are prioritized and placed on the top of the backlog so that the scrum team knows what to deliver first.  PBIs could include:

  1. New features/modules
  2. Enhancements to existing features
  3. Bug fixes
  4. Technology upgrades and data updates

Requests of the above PBIs could come from various stakeholders such as customers, users, management and project sponsors.

Maintaining the Product Backlog: the key to project success

To derive the maximum value of the product, the product owner must effectively manage the backlog. A well-managed backlog is a continuous process and can make sprint planning much more effective. Managing the product backlog is like conducting an orchestra which requires constant synchronization to avoid a cacophony and produce the best symphony.

Here are 7 simple yet effective steps that can go a long way in helping the product owner maintain a healthy product backlog.

  1. Define periodic goals
    Defining time-specific project goals is the first step in turning the invisible into the visible. Goals are defined on the basis of the vision of the product. At the beginning of the project, we might have many requirements in the backlog and limited resources to achieve them. Hence, prioritizing the requirements is imperative and goals help us achieve the same. As shown in the above diagram, setting periodic goals enables us to map the features that need to be developed to achieve the set goals. For example, the goal for Q2 is to secure the application and obtain penetration testing certification. Based on this goal, the PBIs that need to be prioritized for the sprints in Q2 would be related to enhancing the security of the application like having a multi-factor authentication for login, fix vulnerabilities related to SQL injection or the application should recognize a trusted device.
  2. Do not miss any requirement however small
    As the product grows and is being actively used, the flow of requirements from various stakeholders could be overwhelming. Whether it’s a simple requirement, a small bug or just an idea bounced by a stakeholder, it should be captured in the backlog. If not, then such requirements will be overlooked in the backlog grooming sessions. and will never get analyzed and implemented E.g. A customer or any user of the application, reports an issue via an email. The same should get logged in the backlog so that it can be tracked and prioritized on the basis of the severity.
  3. Prioritize the backlog
    A backlog without priority is like a ship without a rudder. Lack of priority can cause ambiguity and can lead the scrum team to spend their precious time wondering ‘what’ to do next rather than ‘how’ to add value. It is the product owner’s responsibility to prioritize the product backlog and define the sprint backlog in conjunction with the scrum team. The sprint backlog is the list of items committed by the scrum team in a given sprint. As shown in the above diagram, each PBI in the product backlog is tagged with a sprint number displaying its priority in the entire list. During the sprint planning session, the team picks up the top PBIs from this list and puts it in the “things to do” list for the current sprint. If the requirements or the priority of the requirements are not clear, then they can be parked at the end of the list and tagged as TBD (to be determined). If the requirements have become obsolete, then such requirements should be deleted or tagged as ‘not required’. This ensures that we have a filtered list to focus on.
  4. Prioritize within the sprint backlog too
    As the requirements become clearer and get prioritized, we pick PBIs from the product backlog and move it to the sprint backlog (as shown in the above diagram). A sprint backlog consists of user stories and associated tasks to be completed within a sprint. It is important to prioritize the items within a sprint to ensure that the most important items get delivered in the given sprint and incomplete items if any can be moved to the next sprint.
  5. Tag stories with epics
    While maintaining the backlog, every story should be tagged with an appropriate epic or module. This helps us to understand all the requirements related to a module and it also tells us how much work is pending or how many features are yet to be developed for the entire module to be called ‘done’. A story might impact 2 different modules and it is very natural for a product owner to tag it to both the epics. However, from my experience, it is important to tag it to the most appropriate epic since epics are usually considered “high-level” items and stories are the smaller, more defined pieces of that item. If there are multiple impacting elements, then the same can be added as labels or tags.
  6. Do not succumb to unnecessary pressure from screamers
    Every project has multiple stakeholders and few of them scream by sending continuous emails, raising their voices, etc. with the sole purpose to get their work or feature prioritized. The product owners should not succumb to such pressure tactics and should learn to say “no” or at least “not yet” to such screamers keeping in mind the cost and benefit implication of each PBI to the overall project goal.
  7. Schedule regular grooming sessions
    Product backlog grooming sessions are like car servicing sessions. Both need to be done regularly to ensure a smooth ride. Grooming sessions also known as product refinement, include discussing details of the prioritized requirements, splitting larger items into smaller ones, estimating user stories, re-assessing the relative priority, removing the “not required” requirements. Regular grooming sessions prevent from creating a ‘Starved’ product backlog. It also ensures that the entire team is aware of the big picture and are not thinking in a tactical sprint by sprint manner.

The product backlog is constantly evolving and is dynamic in nature. As long as the product exists, its backlog also exists, and this backlog should be well-maintained to create a winning product.

Loading Likes...
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.