The Importance of the Product Backlog

As we have reviewed in one of our prior articles, the Product Backlog is the list of incremental product features or functionality that the product owner expects on the product. This is the list the Scrum Team would refer to at the beginning of each sprint and choose the top priority features to enhance the product. So far, so good.

One of the big mistakes organizations that are new to adopting Scrum do is to underestimate the importance of the product backlog. The purpose of this article is to help you understand why the Product Backlog is crucial to any scrum projects success.

To Understand why Product Backlog is Important – Imagine this Scenario in the Sprint Planning for the 1^st Sprint

The entire team is assembled in the meeting room including the scrum master and the product owner. This is the first sprint and everyone is excited to get started on the next batch of product enhancements. However, there are no user stories ready nor are the details ready. What do you think would happen?

The product owner will try to visualize and document the product enhancements as part of a user story and then the team will start analysing the story so that they can estimate it and get started on the work. The first few days of the sprint is going to be wasted before the team has at least one or two user stories that are in “Ready” state for development. Of course, if the team is big, just one or two stories may not be enough to fully utilize the team and hence we are probably going to waste a few days of every team members time until we have sufficient user stories for everyone.

Not to mention the cascading effect this is going to have on subsequent sprints as well because in this Sprint the product owner would be struggling to supply enough stories to keep the team occupied and by the time there are enough stories, Sprint 1 is over and we would’ve reached Iteration Planning day for Sprint 2 and are again back to the same state where the backlog of stories or requirements is not ready.

Do I need to explain more about why the Product Backlog is Important?

Real Life Trivia:   The example above is not fictional and I have seen that happen in many projects where the product owner or the team did not spend time preparing for Sprint 1 and majority of sprint 1 was spent getting the backlog ready and the product output of Sprint 1 was barely anything worthwhile. 

Pre-Sprint Readiness Check of the Sprint Backlog

Experienced Scrum Masters do not wait until Day One of the first sprint to find out whether the product owner has gotten started on the product backlog. They usually identify a few key members of the team and have them get started on discussions with the Product Owner on the potential product enhancements at least a few days (or even weeks) prior to Sprint one. This way, the preliminary backlog of user stories or features is ready before Sprint 1 starts and there is no wasted effort.

An argument here can be made that no work should begin before the start of the Sprint and if we have people working on user stories prior to sprint 1, aren’t we deviating from what Scrum recommends?

Yes, this argument is quite valid but Scrum does not actually recommend that. One of the assumptions in Scrum is that a “Well Defined” product backlog is ready when we arrive in the iteration planning meeting. Without this product backlog the team cannot build anything product in that sprint and hence it is assumed that some work would’ve gone into getting the product backlog ready before the Sprint planning. Get the picture?

In one of our earlier articles on Scrum Meetings, we had a meeting called the “Backlog Refinement” meeting where the product owner and a few members of the team get together to review the product backlog to understand the complexity & relative priority of the important items so that the next iterations planning meeting can be fruitful. It’s the same concept here and we have some members of the team working on the product backlog so that right from Sprint 1, the team is able to deliver incremental product upgrades.

Real Life Trivia: Some Scrum Teams even have a Sprint 0 where only a few members of the team and the product owner get started and their goal is to prepare the initial product backlog before we start Sprint 1. What we name this preparatory period is entirely up to us but the idea here is to make sure there are enough backlog items for the team to be productive from the start.

Have you faced such situations in your scrum projects or have any inputs for fellow scrum masters? Do sound off on the comments.

Scrum Artefacts

In the previous article we covered the different meetings we could have in a Scrum Project. In this article, we are going to look at the various artefacts that are maintained in any scrum project.  

Product Backlog

The product backlog is arguably the most important artefact for the scrum project team. The Product Owner maintains this backlog which contains the prioritized list of product features or functionality that need to implemented with higher priority items on the top. At the beginning of each iteration, the scrum team will pick up the top ranked items and work on them. Some important points about this product backlog include:

• It is a force ranked list of functionality with every item having its own priority
• No two items can have the same priority
• The list is visible for all stakeholders
• Any stakeholder including the scrum team, can add items to this list/backlog
• The product owner maintains the priority of the items in the backlog
• It is updated & refined regularly, preferably in each scrum sprint during the backlog refinement meeting

Product Backlog Item

As we just saw, the product backlog is a prioritized list of items and they are called Product Backlog Items. Each of these items could be individually built, tested and shipped. In most scrum projects, these items are often written as User Stories. Each story has its own detailed requirements as well clearly defined acceptance criteria. The stories are usually sized in such a way that a few members of the team can finish the story within a few days (at max within a single iteration). Some important points about these product backlog items include:

• It specifies the “What” aspect of the feature to be incorporated into the product
• It is usually in a User Story format
• Has specific and clear Acceptance Criteria
• Can be estimated & implemented by the team individually

In some cases, it may not be feasible for the team to build the user story in entirety during a single iteration. Such stories are called “Epic Stories” and are broken down into smaller more manageable sized child stories and each of these children are individually implemented by the scrum team.

Real Life Trivia: A Major point of contention between the scrum team and the product owner is often times the acceptance criteria for a user story. Experienced scrum masters will make sure that when a story is selected for development during a sprint, the story’s acceptance criteria is clearly and unambiguously defined. Some people also call this as the “Definition of Done” which the team needs to accomplish to say that the story development is completed. 

The Sprint Backlog

The spring backlog is nothing but the product backlog items that are shortlisted from the overall product backlog as the potential items for inclusion in the current sprint. This list is identified as part of the Sprint Planning meeting during the beginning of the Sprint. The Scrum team commits to a certain scope at the start of the sprint and focuses on getting them completed during the Sprint. These committed backlog items are usually categorized into 3 major groups – Tasks Not Started, Tasks In Progress and Tasks Completed. A sample backlog chart would look as below:

Some important points about the Sprint Backlog include:

• The backlog is decided based on the commitment by the scrum team and is often times negotiated to achieve certain business objectives as envisioned by the product owner
• The backlog does not change during the sprint execution
• If additional tasks are identified by the scrum team during sprint execution to meet the scope committed during the sprint, they will be added to the list
• The list is used as reference during the daily scrum/stand up meetings
• The list is transparent and visible to all team members

Some scrum teams use electronic tools to represent this sprint backlog while many scrum teams prefer the old school approach where team members put up sticky notes on a white board.

Real Life Trivia: In the “Ideal” scrum world, there is no such thing as a commitment from the team with regards to what will be delivered in a Sprint/Iteration. The team will make a best effort attempt at delivering the user stories identified as part of the sprint backlog and if they are unable to do so (for whatever reasons they may be) the unfinished go back to the backlog and may be prioritized again for continuation in the next Sprint. However, in “Real life” projects, we don’t have this luxury. As we are working toward a product goal (which invariably would have a client impact) the team is expected to keep their commitment for the Sprint and deliver the functionality that was planned during the iteration planning meeting.

Sprint Task

Once we have the committed backlog for a particular sprint, the team will start breaking down the backlog items into more granular tasks. The tasks will address the “How” part of achieving the “What” mentioned in the Product Backlog Item. Each of these tasks is typically 1 or 2 days’ worth of work and each PBI could have more than one team member working on their tasks collaboratively to achieve the PBI’s acceptance criteria. Some important points about the Sprint Tasks include:

• Each task would require a few days of work (Ideal recommendation is at max 1 or 2 days)
• The remaining effort is re-estimated daily for all tasks during the daily stand up
• Usually one member of the team will be primarily responsible for each of the tasks
• A single backlog item could require multiple sprint tasks like analysis, design, implementation, deployment, testing etc. They are all taken up during the same sprint by one or more members of the team collectively.

Sprint Burndown Chart

The Sprint Burndown Chart as the name suggests shows us the work progression by the team wherein we start off with the 100% pending work to be completed on Day 1 of the sprint and work our way towards 0% pending work on the last day of the sprint. Every day during the daily scrum/stand up meeting, the team will share updates regarding the completion of tasks and collectively the team works towards finishing all of the planned backlog items for a sprint by the end of the sprint. That is why it is called a “Burn Down” chart where we target to hit 0% pending work before the end of the sprint. A sample Burndown chart would look as follows: 

While the “X” axis is straight forward and has the dates for the iteration, you may be wondering what the numbers on the “Y” Axis of this chart represent. They represent the amount of work left.

Real Life Trivia: You might be wondering why does the burn down chart go up instead of down during the initial days of the sprint. That is because, when a sprint starts, during the first few days the team is still in discovery mode finding out more work items which would eventually need to be finished for the backlog item to be marked as “Completed”. Hence the small spike during the first few days and the gradual progression towards 0 as tasks gets completed one by one.

Some important points about Burn Down charts include:

• On a daily basis, this chart can show us the total work that still remains (in hours or days – depends on the teams preference) for a particular sprint
• The chart is updated daily and tasks are also re-estimated daily to ensure the chart is an accurate representation of the pending work
• It helps the team self-organize and focus on pending items

Real Life Trivia: In many organizations that have recently adopted scrum practices, the burn down chart becomes more of a management reporting tool rather than a tool to facilitate self-organization within the team. In such a case, this becomes more of an impediment to the team because people with authority over the team are constantly monitoring the progress and the teams efficiency could come down as a result of this constant supervision. In such cases, the Scrum Master should take the initiative to discontinue use of the burn down chart and allow the team to work without such distractions.

In some organizations, apart from the sprint burndown, they also track something called as a Release Burndown chart where they track the completion of product backlog items over the course of multiple sprints. As with any product, the product backlog grows constantly and it is very rare for this burn down chart to hit 0% pending stories because companies constantly enhance their products and it is more of a matter of priority where low priority enhancements will stay in the backlog and get replaced by higher priority enhancements.  Usually Scrum Teams will use the term called “Story Point” while estimating user stories as well as tracking completion. For a release level burn down the number on the Y axis could be Story Points left while for Sprints the Y axis could represent maybe Days or even a more granular measurement factor. People who are very fond of the Waterfall methodology (or are unable to forget it) may choose to have a burn down that represents pending work in Man Days even for Releases.

On a related note, In scrum projects the scrum master captures a metric called “Velocity” which signifies the number of story points of work completed by the team in each iteration. The average velocity of the previous iterations could be a decent yardstick for the management team to predict the potential number of sprints the team may need to finish the remaining items in the overall product backlog. Don’t worry, you will learn more about Velocity and Estimation very soon.