Product backlog contains list of desired functionalities of an envisioned end product. It provides the bigger picture than the sprint/iteration backlog. If product backlog is neglected and treated as a dumping ground, it can distort the bigger picture and impact the iteration/sprint planning. In essence, a well-groomed product backlog is a prerequisite for a successful sprint planning meeting. As part of product backlog grooming exercise:

- New items are discovered and described.

- Existing items are changed or removed as appropriate.

- Items are prioritized. The most important items being at the top.

- High-priority items are decomposed and refined for upcoming sprint planning meeting. 


But this poses few questions:

- How much time should be spent in product backlog grooming?

- How frequently product backlog grooming should happen?

- What are different ways to product backlog grooming?

- How product backlog grooming exercise can be made efficient over time?


In this session, we will touch base on 

- the factors resulting in growing product backlog

- the indicators of unhealthy product backlog

- the impact of unhealthy product backlog on the product development

- the various approaches to take control of the product backlog 

- the tips for maintaing a healthy product backlog


2 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session


In this session, we will touch base on 

  • the factors resulting in growing product backlog
  • the indicators of unhealthy product backlog
  • the impact of unhealthy product backlog on the product development
  • the various approaches to take control of the product backlog 
  • the tips for maintaing a healthy product backlog

We will also see transition of an unhealthy backlog to a healthy backlog via an example.

Learning Outcome


  1. Understand importance of product backlog grooming
  2. Know early indicators of unhealthy product backlog
  3. Learn various ways of product backlog grooming




Target Audience

Business Analyst, Iteration Manager, Product Owner, Project Manager

schedule Submitted 5 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Deepak Dhananjaya
    By Deepak Dhananjaya  ~  2 years ago
    reply Reply

    Hameet! what do you refer as  "healthy backlog". What would happen to an idea that is never prioritized by the product owner? Does it discarded or kept somewhere else? 

    For example, if a website has a christmas seasonal greeting! feature. This may not get prioritized until mid year, so what happens to it. 

    curious to understand!


    • Hameet
      By Hameet  ~  5 years ago
      reply Reply


      Healthy backlog is the one that gives an idea around the product direction. One knows what is lying in the backlog. There are no vague tasks i.e. every cards(epic or story) has a high level notes captured. A person looking at the cards should get an idea about the purpose of the card. If a backlog has high number of cards with unclear purpose, it would be a point of concern for me. This situation should not have occurred in the first place. Unhealthy backlog is result of abusing the concept of backlog.

      • Joel Tosi
        By Joel Tosi  ~  5 years ago
        reply Reply

        Hi Hameet,

          I think I understand the problem you are looking to address / discuss but am failing to understand how you are approaching solving the problem.  Correct me if I am wrong, but you are looking to manage a backlog where the end product / goal is moving and uncertain, causing story fluctuation?  Or am I missing something?  I am missing how you are offering to address that challenge.




        • Hameet
          By Hameet  ~  5 years ago
          reply Reply

          Hi Joel,

          Thru this session, I intended to share 

          - Observed early symptoms of unhelathy backlog ( e.g. cards without priority, proper title, etc.)

          - Some backlog visulizations depicting the trend e.g. monthly burnup trend

          - Tips for avoiding the trap e.g. giving appropriate priority and title while adding the card in backlog

          - Share some techniques to groom the backlog e.g. a tweaked version of Merill Covey Matrix ( In cases when backlog has really grown and you are thinking of ways to trim/prune this)


  • Deepak Dhananjaya
    By Deepak Dhananjaya  ~  2 years ago
    reply Reply

    HI Hameet,

     Would you like to present it with some examples? your own examples? some of your experiences? I see a value add in doing so.


    • Sachin goel
      By Sachin goel  ~  5 years ago
      reply Reply


      As I understand the focus is on managing the product backlog. Have you formulated some tips / techniques/ strategies to do so effectively? Did you manage to apply / present such in different context / situations and see them still working?

      thanks - sachin

      • Srinath Chandrasekharan
        By Srinath Chandrasekharan  ~  5 years ago
        reply Reply


        When you say "backlog in control" are you saying that we restrict the backlog. Isn't backlog supposed to be a placeholder for items which are wish lists. To that extent, should we really control the backlog. 

        Can you give an example of a backlog item that you would not want .

        Also, I am unable to relate it to the theme which is offshore-Sitributed Agile. In your experience, does an offshore and distributed teams have a issue with healthy backlog ?

        Your answers would help us to understand your talk better 





        • Hameet
          By Hameet  ~  5 years ago
          reply Reply


          By "backlog in control" , I mean being aware of what is lying in the backlog . Any thing that gets added to backlog should have a purpose or business value associated. 

          I won't like to see a card that doesn't have a purpose or business value. e.g. card with title 'Fixing navigation' without any description.

          I didn't realize offshore-distributed-team tag was selected. I have removed that now.

      • Liked Jason Yip

        Jason Yip - Think Like an Agilist: Deliberate practice for Agile culture

        Jason Yip
        Jason Yip
        Principal Consultant
        schedule 5 years ago
        Sold Out!
        90 Mins

        If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

        Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

        If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

        My session is intended to expose people to the base of that pyramid.

        If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

        The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

        Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

        NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

      • Liked Prasanna Vaste

        Prasanna Vaste - Should we stop using Story Points and Velocity?

        Prasanna Vaste
        Prasanna Vaste
        Business Analyst
        schedule 5 years ago
        Sold Out!
        20 Mins
        Experience Report

        On Agile projects we estimate user stories in order to allow team to

        1. 1. Track velocity
        2. 2. Decide scope for the Iteration
        3. 3. Help Prioritize stories
        4. 4. Help Release planning

        But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

        Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

        I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

      • Liked Ankush Sabharwal

        Ankush Sabharwal - Step-by-Step Process for Release Planning and Release Level Retrospectives

        45 Mins

        In the session two processes will be explained viz. Release Planning and the Release Level Retro. Step by Step approach will be discussed so that the same can be readily used in your Agile Projects.

        I have created these approaches of conducting effective Release Planning and Release Retrospectives in Agile projects. I have used these processes in various successful Agile projects.


        Note: Please refer to the Links section below to see the steps invoved in both of these processes.