Agile Intelligence: Backlogs

The Agile development process talks about two types of backlogs: Product Backlogs, and Sprint Backlogs. We will talk about the specifics a little later; let’s try to understand the fundamental constitution of backlogs first. Backlogs, unlike the word suggests is not about falling behind. It’s about maintaining a to-do list. A backlog is a master list of all functionalities desired in a product (software application).

The proponents of Agile development are of opinion that the details specification of a software application are not known during the start of the project. So, the obvious requirements are listed down as the product backlog. As the project progresses, the requirements get more elaborated and refined, and the product backlog grows accordingly. While such a statement does not provide enough confidence at the investor level, but works pretty nicely to the people who work on the project.

The backlogs are documented in tabular format. Each backlog has a name (or short description) to it, and a priority mark (high/medium/low) with the respect to the critical success factor. The product owner takes the responsibility to maintain and update this backlog. The product owner gets the inputs from the various groups of potential users and beneficiaries of the software application, and converts those inputs into backlogs with due priority. The product backlog does not have any other project planning attributes attached to it.

The product backlog works as the input to the sprint backlog. A sprint backlog is the list of backlog items that the team commits to deliver in a particular sprint. In a way, sprint backlog is a sub-set of the product backlog. However, there may be additional backlogs into a sprint backlog which are normally the supporting work for the sprint. Sometimes, a product backlog is also broken into multiple sprint backlogs for better granularity and distribution of work. As example, the product backlog may specify that only the employees of the organization will be able to access the software application. At the sprint backlog, this may be broken down into the login pages, authentication module, and integration with the enterprise directory. Sprint backlogs are picked up by the team members, which is largely a self-assignment process. The sprint master keeps track of the assigned work through the scrums. Scrum also helps the sprint master to fill up the start and end dates of each sprint backlog.

The webmasters of the Agile Advice website has brought in the Queuing Theory to understand the backlogs better. The theory helps the mathematical analysis and optimization of the work packages flowing from starting point to the finish line. The theory denotes the entire work package completion path using the time interval of having the work packages for start, the time required to complete the work within each package, and the number of resources (in software engineering, it should be the number of team members) available for the work packages. My personal opinion is not to focus too much on the advanced techniques at the beginning. Just apply some common sense if you are a sprint master. In case you have to apply something fancy, first focus on the principles and best practices of software project planning, tracking, and supervision.