The twenty century has witnessed a major surge in the adoption of Agile with organizations trying to fit into their ways of working to better meet customer demands. As per the 14th Annual State of Agile 2020, 58% of the respondents were using Scrum as the framework for product delivery. The report also mentioned that many considered Agile and Scrum to be the same, which is incorrect.
Agile is a way or method of implementing frameworks such as Scrum, Kanban and the like. It is a time-boxed, iterative way of software delivery focusing on faster time to market and customer collaboration.
Scrum is a subset of Agile. With a great framework like Scrum, Agile gets a runway to deliver quality products in an iterative, incremental, and time-boxed manner.
Talking of product development, whatever the framework, we must start with the creation of the requirement list. This applies to Agile too. Here, we term this as “Backlog”. I am often asked about the origin of the term, “Backlog”. Why “backlog” and why not some other word? Well, the term dates back to the 1680s when large logs were placed at the back of a fire to keep the blaze going and concentrate the heat. By the 1880s, the term was adopted in its figurative sense of "something stored up for later use". So, a Backlog is a prioritized list of items the teams’ need to work for the successful delivery of a product.
How extensively are Scrum artifacts, and in particular, the product backlog and sprint backlog used? Source: 14th State of Agile 2020
According to the State of Scrum 2015 report, surprisingly, only 56% of the respondents reported using extensive scrum artifacts like Product Backlog and Sprint Backlog.
Major success criteria for any Agile project lie in its backlog and it demands a lot of focus both in terms of keeping it refined and updated with current situation. Thankfully, it is the topic of the day, and here we will talk more about it.
The Product Backlog is the ordered list of requirements of all that is required to successfully deliver it to the client. It contains the prioritized list of requirements that can be detailed or vague and has everything that needs to be done for a particular product. One can visualize it as a big bucket that has all the items/necessities needed for a product to be successful and competitive in nature.
The Product Backlog is primarily handled by the Product Owner who takes care of the client's needs and makes sure the product backlog represents the exact requirement. The product owner is responsible for keeping the backlog healthy and in a state that is readily consumable by the team. The product backlog is never frozen, the items can change as per the demand and market scenario. Anyone can suggest items to be added in the list but the final say will always be on the Product Owner.
Let’s look at an example to further understand it better:
Build a mobile application for a local bank so that the users can access the bank on the go. Product Backlog would look like:
|1||Create a sign in page for the users||High|
|2||Create a logout page||High|
|3||Create a home page to land after successful sign in to the application||High|
|4||Create a page for Accounts||Medium|
|5||Create a page for Money Transfer||Medium|
|6||Create a page for Loans||Medium|
|7||Create a page for User Profile||Low|
|8||Create a page for 'Contact Us' section||Low|
There can be multiple other requirements both front-end and back-end to get this mobile application delivered, but, here for understanding, we are just taking a few of them. Each item in the list will have a priority attached to it, this makes it easy for the development team to pick work once they are done with the one in hand. Product Backlog can also be termed as the master list of requirements.
Sprint Backlog is a list derived from the product backlog or the master list. When teams start working in Scrum, they have sprints which are a timebox for delivery, it defines when a customer can expect the shipment and at what intervals. The period can range from a week to a months’ timeline. Here, in sprints, the team pulls the work from the product backlog as per the priority and their capacity and put it in a smaller bucket called ‘Sprint Backlog’. It is like delivering the big Product Backlog in chunks called “Sprint Backlog’. The Sprint Backlog can also be defined as a subset of superset ‘Product Backlog’. For a successful product delivery, both are essential, and hence the need to keep them healthy.
Sprint backlog is owned by the scrum team, and together, they create their sprint board which consists of the user stories, bugs (if any), and spikes. It is the development team who determines the Sprint Backlog. Here, the Scrum Master can facilitate the Sprint Planning meeting to help the team come up with the Sprint Backlog. The scrum team utilizes the sprint planning meeting to discuss on the sprint goal and the commitment they can make for the upcoming sprint. They pull the items to discuss from the top of the list and create their sprint backlog according to the capacity and complexity of parameters.
So, the sprint backlog is a subset of product backlog and going back to our example let's create a Sprint backlog now:
|1||Create a sign in page for the users||High|
|2||Create a logout page||High|
|3||Create a home page to land after successful sign-in to the application||High|
In our example, we have pulled the sprint backlog items from the master list which was already in a prioritized state.
The Scrum Master can help the development team understand the difference between Product Backlog and the Sprint Backlog, this can be done through coaching the teams about the process and the Scrum artifacts and can help the Product owner in maintaining a healthy backlog.
The team uses Product Backlog to create their sprint backlog. During the Sprint planning meeting, the development team should talk about the complexity and the efforts needed to get the job done. They pull the items from the product backlog to the Sprint Backlog to be completed in the sprint time-box.
Effective Product Backlog depends on a clear understanding of the result and the need. The Product Owner must clearly define the requirements that have details enough for the team to get a clear picture of what is needed to be done. The product backlog needs to be a thorough list of all the work that must be done to get the project delivered successfully.
Once a high-level list is created, the development team can help in further refining and creating an exhaustive backlog with all the technical aspects needed to deliver the functional side. Creating a backlog should be a collective team effort, this also helps in bringing about the ownership and collaborative environment amongst the group.
Though the development team can help the Product Owner in creating a proper efficient Product Backlog, the sole responsibility for the Product Backlog lies with the Product Owner.
Once you have a good Product Backlog, pulling out the Sprint Backlog gets easy. Sprint Backlog gets its shape during the sprint planning meeting which is the first thing in a new iteration where the team sits together, either, physically or virtually, to discuss the requirements they can work on in a new sprint.
Essentially the discussion circles the functionalities, the technical aspect around it, and how much they can load in an iteration. Here, the Scrum Master can help the team with excellent facilitation skills to come up with a sprint goal as a joint team effort. The team pulls up the highest priority items from the product backlog to discuss functionality and complexity, they also converse on the steps they could take to reach the goal.
Prioritization is one of the critical aspects of a Product Backlog that helps in keeping it in a healthy state. Let’s look at a few of the benefits of prioritizing the backlog:
After talking about the Backlog and its benefits, let’s look at the various techniques of prioritization:
Developed by Dai Clegg, this is the most widely used model while prioritizing the backlog. The name itself has the meaning - Must Have, Should Have, Could Have, and Won’t Have.
In the 1980s Kano Model was developed by Professor Noriaki Kano. Under the Kano Model, items are categorized according to the requirements and opportunities of the stakeholders. The categories are – ‘Basic expectations’, ‘Satisfiers’, ‘Delighters’.
During Stack Ranking the items are placed in the order of priority which starts with one and goes up to the number of items in the backlog.
To measure the cost of delay one needs to understand: “What will be the cost per time unit if we delayed delivery?” This is difficult to measure sometimes if you don’t use the correct parameters. This figure states how much money every month it will cost your organization to delay the delivery of the finished project. In practical life, we all have experienced ‘cost of delay’ whether it is starting late for work or starting up late with a new assignment.
In conclusion, we have seen that both the Product Backlog and Sprint Backlog are different entities tied together to the same group.
Backlogs play a crucial role in software delivery and help the team deliver efficient solutions through effective backlog management tools and techniques. Once teams understand and use their backlog effectively, they are sure to achieve better delivery, serve customers better and enable the management to seize new opportunities.
Your email address will not be published. Required fields are marked *