01 October 2020
Backlog management in software development. Why you should care
Probably each of us at least once in their life completed the list of tasks that must be performed to achieve a certain goal. Creating and modifying tasks accompany us in everyday life, whether we go shopping, on vacation or plan furnishing the apartment. In each of these cases, there are some tools that may help us to better organize our time. Obviously, the planning should start with creating a to-do list. It is similar to when you are creating a product or developing a new or existing system. Below, I’ll try to explain the role of proper backlog management in software development. And I will answer the question how to manage product backlog.
If we want to do our job well, we should make a list of tasks which need to be performed. In the IT world, we call such a list the Backlog. In the backlog, you will find the tasks to be performed to complete the project.
It should be managed by the Product Owner – the person responsible for setting the direction of the project development. At first glance, everything seems clear – we have a to-do list and a person responsible for distributing tasks from the list. Nevertheless, the Backlog issue is more complicated than it may seem.
So what is a backlog? In terms of product – it is a list that contains information about all the requirements for the system being created. It does not matter whether we are talking about functionalities, plans for system development, non-functional requirements or errors reported by users. You might think about this as a big sack into which we throw all ideas that come to our mind and are related to our project with all the bugs reported by users, testers or developers. I have already seen Backlogs conducted in such a way, where the list of tasks waiting for implementation could exceed three-digit numbers (sic!).
Attributes of a good Product Backlog in Agile
Product Backlog management has some certain attributes. It’s important to define backlog using these. The tasks that are in it, whether it’s Epic, User Story (or User Stories), Task, Use Case or another form, should have a description. It should be legible enough for a new team member who joins product development (and basically all the team members) to understand what the task is about and what the final result should be.
Another Product Backlog attribute is the value of its elements. Each task brings some change with it. Its value can be positive or negative if this change is not implemented. Therefore, each element of our list has assigned value to make sure we know how important it is to complete this task quickly. Nevertheless, in order to plan the upcoming workload properly, it is also worth knowing the time-consumption and complexity of a given task. The so-called task estimation is the third attribute in the Product Backlog. There are several methods of estimating tasks, but the most important thing is that the estimates are understandable to everyone. It’s because on their basis and the basis of the previous attribute, i.e. the value, the Product Owner and the team can plan the next steps of creating the project. The last attribute of a good Product Backlog is the order. Putting the tasks in the right order is largely the responsibility of the Product Owner when managing product backlog. They should arrange the tasks in such an order where at the top of our list there are tasks ready for implementation, and going down the list includes large tasks that still require discussion and analysis.
The Product Owner’s decisions should be based on various criteria: a combination of values and estimates and all the conclusions coming from consultation with the development team and project stakeholders.
See also: How to become an IT Project Manager?
It’s good to top our list with enough tasks that will allow us to work through the two upcoming Sprints (if the team works in Sprints, obviously). What does it mean? Knowing the performance of our development team and having task estimates at the top of our list, we can move tasks that will more or less allow our team to deliver these elements within two Sprints.
Discussing tasks for a longer period of time does not always make sense, because the dynamics of changes that take place in business may cause a quick change of priorities and then our time could be wasted. Another important approach is to put tasks that meet the so-called Definition of Ready at the top of our list. It is an agreement between the Product Owner and the development team on what elements the task should have before it goes to the implementation phase.
What is worth paying attention to is whether the task has, for example:
- description – thanks to that we will know the business value of the task;
- acceptance criteria – thanks to that we will know what the customer expects and will also allow us to conduct appropriate tests;
- designs – if it is a task with new graphics, it is worth having it delivered to the task;
- user path – the so-called happy path – very often when using the Gherkin language, it allows us to learn the next steps that the user will take.
These are just some of the points worth paying attention to. Each team may have a different Definition of Ready for the task, but you should remember and watch over it.
Once we have the Product Backlog set up accordingly, we can move on to the next list – Sprint Backlog. What is that? The Scrum Guide says this:
The Sprint Backlog is a set of Product Backlog items selected for the Sprint, plus a plan to deliver the Product Increment and meet the Sprint Goal.
Pretty simple, right? 😉 But let’s start from the beginning.
Sprint Backlog is created during Sprint Planning. Items that go to the Sprint Backlog come from our previously discussed Product Backlog. You should keep in mind that the Product Backlog may be a to-do list for multiple teams working on one system, but the Sprint Backlog is a to-do list for just one specific team.
When planning the next Sprint, the team decides which elements they will be able to deliver. It often happens that you need to add more tasks that are required to implement the assumed plan. The development team is the owner of the Sprint Backlog. It’s the team’s responsibility to manage individual tasks that are on the list to be performed. This means that the team has control over the elements on which they work.
If during a Sprint there is a need to add, modify or delete anything in the Sprint Backlog, this can be done by the Development Team. The team doesn’t have to ask anyone for permission, as long as it doesn’t change the scope of the Sprint. Of course, there may be a situation (it’s quite common by the way) that during the Sprint, the Product Owner wants to change the scope of the Sprint, or even the team reports that there may be a change in this regard for various reasons. In such situations, when there is a change of priorities, the tasks should be replaced accordingly, i.e. the task shows up and some others should be removed from the Sprint scope.
It is important that the tasks are very similar in terms of their complexity and timeframes. Another situation, more positive, is when the team reports that it has completed or is close to completion of the planned scope of the Sprint and may undertake further tasks. Then, after consultation with the Product Owner and the team, another task may be selected for implementation.
During Sprint Planning, the most important question should be asked. Namely – what is the goal of the next Sprint? On this basis, we can select the appropriate tasks to achieve the goal and, what is very important, prioritize the tasks on our list in the Sprint Backlog. It is good practice that the tasks that fulfill the Sprint goal are also close to the top of our list for the next Sprint and that they are carried out by the development team first.
Now we come to the most difficult moment – managing our lists. Merely writing down tasks, organizing and estimating them will not do much if we do not update our lists. To make this process easy to do, our lists should be placed so that everyone has easy access to them. For this purpose, we use the so-called Scrum Board or a publicly available plain board. As I mentioned before, for our two lists, we have other people responsible for keeping them in order. In the case of Sprint Backlog, the team is responsible for the order. Very often, tasks are updated during the Daily Standup Meeting. It mainly consists of “dragging” the task to the appropriate column on the board and adding the appropriate comment. It all depends on what the team agreed on and how they set up the board.
The Product Backlog is a more difficult task. The Product Owner is (or at least should be) the main person responsible for the transparency of this list. This does not mean that other stakeholders cannot add anything to this list, but remember that the last word belongs to the PO. As I mentioned before, Product Backlog can very often resemble a bottomless well into which further suggestions and ideas for the development, improvement and repair of our project are thrown. Fortunately, it’s time to clean up this list, i.e. Refinement, during the development work. This is the process by which the Product Owner (often in collaboration with others) adds, adjusts, grooms, and prioritizes backlog items within the backlog to make sure the most valuable product is shipped to customers. This means that during the Refinement, the existing elements on our list are reviewed, detailed and very often also estimated.
The meeting also aims to set priorities for the next period of work as well as look into the depths of our list and decide if everything has to be delivered. It is worth taking care of order on our lists, but also applying a certain filter when adding new elements to it.
It happens that some extensive Backlogs cause numerous problems, such as:
- Costs of maintenance – each item on the list means that we have to think about its sense and analyze it, otherwise we waste our precious time.
- Reducing the value and innovation of the Backlog. With a large list, it becomes quite a basket. It may have a negative impact on the team and other stakeholders, because they will not see the point of adding more items, as they will never be implemented.
In order to avoid such problems during project management, it is worth having a person in the role of Product Owner who is strongly involved and understands their responsibility for running our Backlog. It is also worth determining the process of submitting subsequent elements to the list and applying some kind of filters of the type of questions about the business need of the new element. From my practice, it is also worth adding a kind of marker, such as: ready for refinement, ready for development. Above these markers, we set tasks that meet our Definition of Ready before Refinement and then before handing this task over to developers.
To sum up –creating the list itself is not difficult. But keeping it in a clear way and updating it is difficult work. But certainly doable. Good luck!