Product Backlog

The fuel for an Agile journey

8 July 2014

Raj Kumar Sahu
Wipro Consulting Servies


When any organization implements Agile, multiple challenges arise. By now, all of us know the common challenges, which I think are not necessary to highlight. This is inevitable. With time and proper coaching, the organization/teams will learn and improve. This is what we refer to as "continuous improvement."

Apart from the common challenges, however, I personally feel one area to focus on is product backlog management. I have seen organizations/teams overlook this aspect because of other challenges, or compromise here because of lack of knowledge. I say this based on my involvement with multiple Agile projects where I have worked as an Agile coach or ScrumMaster. I have a strong impulse to compare the product backlog with "fuel," and below is my reasoning as to why I want to term this discussion "Product Backlog -- The Fuel for an Agile Journey."


Before I start on this journey, I would like to let you know that the content has been produced from the information provided/shared in various Agile workshops that I have attended and blogs that I read through various forums of Agile professionals, apart from my personal experience. I would like to acknowledge their direct/indirect contribution toward this paper, which is primarily for the experienced Agile practitioner. As Scrum is most widely used, the examples/terms used in this paper are mostly aligned to the Scrum framework. The recommendations below have to be carefully evaluated along with the Agile environment before being implemented.

Why "fuel"?

Let's look at a transport system -- the railways, for example. Each train has its own start time and end time for its journey. When it is time, the train starts from its source and travels toward its destination and arrives there on time (assuming no interruption). For the transport organization to work effectively, they would ensure that they have a sufficient fuel reserve. Not only quantity but also quality of fuel is equally important, as it ensures that the transport system runs for a longer duration without major wear and tear or need for extra maintenance. In summary, fuel should be readily available (both in quantity and quality) for the success of the transport system.

Fuel for an Agile journey

Similarly, Agile is a journey. As with trains, we say our journey is timeboxed (time is fixed, unlike in the traditional Waterfall method, where scope is fixed). Everything starts on time and ends on time. The fuel for a sprint to start with consists of the user stories (US) from the product backlog (PB), also known as product backlog items (PBI). We should ensure both quantity (sufficient for the team to work on, based on its velocity) and quality (well groomed, detailed appropriately, estimated, emergent, prioritized).

Symptoms of bad fuel

Before getting into the recommendations, I would like to put in some of the symptoms of problems you might see in your Agile projects, whose root cause can be the product backlog and the way it is managed (who/what/when/how).
  • Sudden increase or decrease of product backlog scope that too often impacts the release plan, creating confusion on the product road map
  • Team committing less than its capacity or being underused because of lack of a good product backlog
  • Just before the start of execution (maybe during sprint planning), debates or discussions about an approaching epic, resulting in dropping a user story from the sprint in which it was meant to be of the highest priority
  • Debate or conflicts between the team and the product owner during user story review/acceptance, because the scope or the acceptance criteria is not clear or complete
  • Teams feeling that they are either not involved or are overinvolved in backlog grooming; high probability of getting this observation in the retrospective
  • Lots of user stories created during sprint planning, all to be executed during the same sprint


Below are some recommendation that have helped my clients and teams not run out of "fuel" and avoid any of the above-mentioned problems and their symptoms. To describe my observation, I have categorized two types of Agile teams (irrespective of whether it is collocated or distributed Agile):
  • Single Agile team (one team working on one product backlog)
  • Multiple Agile teams (more than one team working on one product backlog

Challenges for single teams and multiple teams

I will start with some common recommendations that are applicable to both of the above types of Agile teams.

Ownership/Responsibility: We all know the PO has the key responsibility for product backlog. I have seen PO's delegating the responsibility (maybe through a proxy PO), and they may have valid reasons for doing so. For example, the PO may have more of a marketing and sales responsibility, or the product may have a wide customer base wherein his/her time goes into meeting with them. Also, the project may be more technically oriented, so that an architect may act as a proxy PO. Practically, there may be multiple business analysts or support product owners who provide support to the prime product owner. This could lead to confusion about ownership and lack of responsibility from the prime product owner. Since the PO is the prime role that provides the goal and direction to the teams, any ambiguity in ownership/responsibility would be disastrous.

Suggestion: Whatever may be the case, there should be one and only one PO who fully owns responsibility for the product backlog. Everybody would agree that it is very difficult when one has to report to two managers at the same time. Similarly, the product backlog loses its focus if the ownership lies with more than one person.

Time to be spent on the product backlog: Going by the recommendation of the Scrum framework, spend at least 10 percent of the sprint on product backlog grooming. To provide a calculation, each team member would be required to spend at least four hours for every sprint week, or one day for a two-week sprint. Are we really spending that much time? I have seen people neglecting this and meeting for only one hour every sprint, as if it were just another ceremony to be conducted once in a sprint. And then they struggle when they see the backlog not ready or changing (additions or deletions of scope) during the sprint.

Suggestion: Spend enough time so as to maintain a good backlog reserve. What is a good backlog reserve? Refer the next section.

Backlog reserve: I have observed, especially where more than one team works on the same product backlog, that the teams run out of user stories (or you could say quality user stories) to be worked on during the sprint. The prime reason is that the rate at which the team churns user stories to shippable product (i.e., velocity) is more than the rate at which the product backlog items are groomed and kept sprint-ready.

Suggestion: At all times, keep user stories sprint-ready or execution-ready in the product backlog for the next one-and-a-half to two months (three to four per sprint, considering a two-week sprint). I know it cannot be 100 percent because of the fundamental reason of "accepting changes even late in the game," but all would agree that the change percentage should not be much.

Below is how you can calculate the backlog reserve story points that should span across the agreed backlog reserve sprints:
Focus on the backlog: The product backlog and its grooming are considered to be regular activities in an Agile project. The problem I have seen is that people give equal importance to the backlog throughout the project life cycle. For this reason, some teams struggle at the beginning of the project, and some teams are very much relaxed at the end of the project (release). Getting relaxed at the end is fine, but the impact during the struggling period is high. Agile teams would sit idle because of the lack of a good product backlog.

Suggestion: Spend more time at the initial phase of the project (initial release/sprints) and, if required, reduce the capacity during the initial sprints and spend quality time on backlog grooming. Do not worry about the velocity for the initial sprint, because you are actually ensuring that you are prepared for a good velocity once the team starts working fully. If the question is how much focus, I would again suggest ensuring a good backlog reserve as defined above.

Exploring user stories: I have seen many instances when Agile team members are surprised to see an epic arise just before execution (one to two sprints before). This impacts the confidence and morale of the teams, as they cannot be sure of the product backlog items, which can come up at any time. The broader perspective of the product seems to be missing, which also results in bad release planning.

Suggestion: The user story should be iteratively explored with the teams at least four times before it is actually executed in a sprint:
  1. As a high-level epic, at least a release before execution
  2. As a story or a set of stories, three to four sprints from execution
  3. As a story, one to two sprints from execution
  4. As a story, right before execution

Spike user stories: Many times, user stories are written with a lot of assumptions of complex product/design. When it comes to sprint planning, the team members find them difficult to execute due to their complex nature. This results in a dead stop or, as an alternative, a not-so-ideal path taken in order to complete the user story at hand.

Suggestion: Have a spike to explore the complexity, confirm the assumption, and create user stories for actual execution based on the spike. Create spike user stories to be worked on in the upcoming sprint for a feature that you may plan to actually work on one to two months down the line.

Challenges specifically for multiple teams

While I have seen fewer problems for single Agile teams, I have seen multiple challenges when it comes to multiple Agile teams. I have explicitly outlined a few such challenges and recommendations for these multiple Agile team situations below:

Who should attend the backlog grooming meeting: Based on the skills required for the project execution, the PO can invite appropriate stakeholders to get involved. It is also good that all the Agile teams get involved in backlog grooming. The challenge here is that all teams attend, assuming it is a mandate and would be helpful down the line in execution, but in reality the meetings become ineffective because of multiple views coming in for one discussion. In a way it is good -- more views can give more value to the product -- but as we focus on "just enough work" to be done, it may not be needed at this stage. Often I have seen many members not contributing because they are not sure whether the epic being discussed will actually be executed by their team.

Suggestion: Have a two-phase meeting for backlog grooming. This can be done in two ways:
  • Members from the Agile team are fully involved from beginning.
    • Backlog grooming meeting: Involve SMEs/senior members/team representatives from the Agile team during backlog grooming, rather than the full team. As the PO knows the priority of features and the feature he/she wants to groom, he can invite the respective stakeholders (SMEs/senior members/team representatives) only, and get the backlog groomed.
    • Look-ahead meeting: Once the backlog is ready, the complete Scrum teams involved in the execution can be called to look at the groomed user story and size it further.
  • Members from the Agile team are involved in the second meeting only.
    • Backlog grooming meeting: Create a permanent team of SMEs for the product being developed and use them to groom the product backlog, with direction from the PO. Ideally, this team should consist of people who have good product knowledge and most likely were part of the Scrum team for the product in one of the earlier releases. These members can be rotating in and out of the Scrum team between releases.
    • Look-ahead meeting: Once the backlog is ready, all the Scrum teams involved in the execution can be called to look at the groomed user story and size it further.
Note: The product backlog grooming meeting agenda is to add/delete/refine/prioritize/estimate user stories by a specific team, not by the complete Agile team. On the other hand, the look-ahead meeting agenda is to understand/clarify/estimate the newly added or groomed user stories along with focusing the user stories for the upcoming sprint and calling out dependencies (if any) for a better and smoother upcoming sprint execution.

In both cases, the Scrum team saves lot of time and still ensures the quality of the backlog, as focused thinking has been put in by the right stakeholders. I am sure there would be some input from the teams during the look-ahead meeting, but, again, there would not be major changes.

While we are talking about product backlog, I would also like to discuss three more aspects that help make the product backlog into good "fuel" and provide better mileage by helping the teams know the time of the execution, the teams involved in the execution, and the size of the execution for better release planning.

Time of execution: Based on the priority as set by the product owner in the product backlog, the team pulls in the user story to work on during the execution. Sometimes the teams identify the dependencies while picking up the user stories to work on during the sprint planning and are stuck.

Suggestion: Epic dependencies are nicely detailed and appropriately scheduled in the various sprint buckets. One key instrument to help is to use story mapping.

Team involvement in execution: We all know that the team decides how they want to work. But when? Most of the time the team assignment to user stories happens during sprint planning, after the team pulls those stories. But there is a challenge when we have multiple teams, as there may be some pre-fetch work that needs to be done before actually picking up the user story for execution during a sprint. The pre-fetch work here refers to calling out dependencies or some minor work that may need to be done before actual execution or next sprint planning. If not done, this will impact the sprint commitment. So the question here is, who is responsible for that pre-fetch work in a scenario of multiple Agile teams?

Suggestion: Assign the teams based on their skill set or experience, or maybe by the team or team representative pulling the stories as early as possible in the user-story life cycle. To give an example, this can be done as early as during product backlog grooming sessions. This helps each Scrum team have a more focused approach to the product backlog items for the assigned work.

Size of the execution: We all intend to have a release plan based on what we have in the product backlog. For a good plan, we should have proper sizing or estimation of user stories in the product backlog. We agree that the team should size the user stories, and we need to have a plan from day one of the project/release. As per my above suggestion, I am trying to involve the team late in the game for multiple-team scenario. So, how do we overcome this situation?

Suggestion: We need to size the product backlog items over various stages, or rather in three phases. As we have L1 (+/- 75%), L2 (+/- 50%), or L3 (+/- 25%) estimates in traditional estimation, we can term these as 25% confidence, 80% confidence, and 100% confidence in Agile estimating. At a particular instance, the probability of an estimate remaining the same in the future can be termed "confidence."
  • Phase I: The SME/senior member/team representative can size it during the product backlog grooming meeting wherein the US is introduced. This can be considered a 25% confidence estimate. You should rarely have 25% confidence-sized user stories in the backlog reserve.
  • Phase II: The team can size the US during the look-ahead meeting once they discuss and clarify the scope with the PO/SMEs. You can consider this size an 80% confidence estimate. These user stories are ready to go to the backlog reserve category and are now sprint-ready.
  • Phase III: The team can size the US again during the sprint planning meeting when they unearth any addition or deletion of scope to what they have seen during the look-ahead meeting. Although 80-90% of the time the estimate or scope does not change, we cannot forget one of the key attributes of the user story or the product backlog items, i.e., "negotiable" (from INVEST). While I suggest this, please look out for symptoms of the size being changed for more than 50% of the user stories during sprint planning. This clearly indicates that the product backlog grooming or look-ahead meeting is ineffective.
Considering the current sprint to be Sprint 1, and the average team velocity to be 60 story points, below is the matrix one should expect for the backlog size:


What to read/observe from the above matrix?
  • Sprint 1 commitment is 62 story points. This is the current sprint. Once you enter into the sprint, there is no change to the estimate.
  • Backlog reserve is four sprints (Sprint 2 to Sprint 5).
  • Most of the user stories falling under the backlog reserve category have been sized at 80% confidence.
  • There can be the rare exception of a user story not sized at 80% from the backlog reserve, as shown in Sprint 4.
  • Going by the average velocity of the team, i.e., 60 story points, the user stories have been distributed across the ten planned sprints based on priority and dependencies.
  • More focus is given to the US that has priority. This is the reason why not many user stories are estimated at 80% confidence for Sprint 8, Sprint 9, and Sprint 10.


Below are some advantages that can come out of maintaining a good product backlog:
  • Continuous grooming results in the product delivering the highest- and best-value feature first.
  • A good backlog provides a clear picture of the product vision and release vision to all the stakeholders and keeps them focused.
  • The team gets good visibility of the product scope and better understanding of "why" the US exists.
  • The backlog reserve helps the team better plan execution.
  • Sprint planning become more effective as the US dependencies are sorted out during the sprint allocation activity.
  • Effective backlog grooming makes the product backlog DEEP (Detailed appropriately, Estimated, Emergent, Prioritized).


Last but not least, I would like to conclude by saying that it is always easy to execute things when they are in place. In fact, if it is in place, anyone can execute it. But the important activity is to keep things in place. This is the "fuel" for an Agile journey, i.e., the product backlog! Keep the "fuel" burning!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (1 ratings)


Tim Baffa, CSM, 7/8/2014 1:55:05 PM

Enjoyed your article. Many excellent ideas to take from it. I did have a few comments:

1) I believe it is imperative to have a backlog reserve in order to support future iterations (always having fuel on hand). However, I am reluctant to advise teams and PO's to refine items that are currently prioritized in the backlog for two months down the road.

I have seen the best success and lowest amount of "waste" when a backlog is groomed for the next sprint and the sprint after (1 month out). This keeps the fuel on hand while limiting the possibility of wasted effort refining items that are de-prioritized.

2) Regarding multiple-team backlog grooming, I would not be in favor of swapping individuals in and out of a team in SME roles. The best way I have seen multi-team refinement work (and recommended by Craig Larman) is to have one team refine a story, and then to have one member from that team meet with the next team to discuss and possibly add more detail/criteria to the story. Continue with all teams that serve that backlog, and then each team is positioned to accept any story offered by the business that satisfies DoR (definition of ready).

3) I would conduct estimation outside of the PBR sessions. These estimates are specific to each team, and should not require input from anyone outside the team, especially the PO.

I would also avoid any estimating being performed by one person or a subset of the team. In my mind, estimates are only valid if the entire team has arrived at a number. To me, an estimate provided that has an implied certainty of only 25% simply adds no value.
Raj Kumar Sahu, CSP,CSM, 7/9/2014 6:53:20 AM
@Tim - Thanks for the compliments and feedback. Happy to hear that you have at least some take-away.

I am sure and you would also agree that not all of my suggestion would work perfect in all scenarios. Each Agile environment is different and implementation has to be customized accordingly.

You have valid points and I assume is best suiting specific scenario. Point Taken.

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.