A product backlog is the definitive list of all the new epics, features (changes to existing features), user stories, bug fixes, infrastructure changes and maintenance items of your software product. It is also the place to add any other additional tasks that a product and development teams may need to perform in order to deliver the next version of the product.

Agile Sprint Deliveries

In todays software development world most products are developed according to the agile doctrine and each micro delivery is measured in sprints (a planned amount of work delivered in a time-boxed iteration). At the completion of each sprint the product backlog is reassessed and additions, changes and tweaks are made to the backlog when required.

Daily Scrum Updates

Typically, the development teams meet each morning and share in an informal manner their current status and any issues that have arisen since the day before.

Single Source of Truth

The product backlog is the single source truth for all the development teams tasks and action items. That means that nothing gets done that isn’t on the product backlog.

Agile Project Management Tools

The product backlog should be maintained using an agile project management tool. Many good project management tool exist. I have listed the products that I think provide the best overall solutions regardless of price, as some of them can be quite expensive to use.

Some of them offer excellent free versions if your justing starting out, have a small team or work for a non-profit organisation.

Highlighted Project Management Tools

I find the following products to be clear, straight forward and easy to use and understand. I have added here specific products that I think are the best professional software project management products currently on the market.

I have provided a brief explanation and an overall score that describes what I consider to be their main advantages. Obviously, there are many different products on the market and also many different opinions.

Jira

A powerful project management tool, customisable workflows, tonnes of features, provides a broad range of integration options with knowledge base collaboration tools.

Cost: Starts at $10/mo for 10 users, scales up based on users.

Score: A great powerful tool, but it’s expensive. No free version for small project starters.

Targetprocess

Provides beautiful pre-prepared layout solutions for each persona type in your project team. A scrum master development flow, an IT manager tickets view and a product owner numbered features lists, as well as tonnes of charts and spread sheets options.

Cost: Free for up to 1,000 entities (“entities” being anything from bugs, requests, tasks, etc). Scales up from $20 per user per month for unlimited entities, premium support.

Score: An excellent all round tool that provide a great free version for a small team or project.

Pivotal Tracker

Supports multiple projects, burn-down charts, messaging between users, project-based tasks, and user stories, easy to use, has a fantastic iOS app, and offers a nice set of feedback tools, so the QA team is always at the forefront of the project.

Cost: Free for three users, 2GB of storage, and two private projects; also free for public projects, non-profits, and academic institutions. Starts at $12.50/month for five collaborators and goes up to $250/month for 50 collaborators.

Score: A good tool that provide a free version for small teams and it doesn’t get too complicated to use.

Typical Product Backlog

The product backlog is a list of every product related task (features, user stories, bugs and ongoing maintenance items) that the development team needs to complete to build the product solution. The advancement of the development process is divided into sprints. The backlog needs to be structured, organised, and arranged to focus on the most important things for your team to work on.

The sequence of product backlog items on a product backlog changes as the product construction progresses. The action items are ordered and re-ordered at the completion of every sprint iteration. This reordering of existing product backlog items and the ongoing addition and removal of product backlog items is dynamic.

These changes to the backlog are made by understandings gained by receiving feedback from both external paying customers and internal test groups that use the newly released (launched) feature or function on the staging or production environment.

Backlog Item Types

Various terms are used to describe the software building block task items, so I have added a brief definition for each item type. A typical backlog comprises the following different types of items:

• Features – A product feature is a slice of business functionality that describes a task or a benefit for the product’s end user. It contain a specific set of characteristics of the product that describe the design, components and capabilities for a specific use case.
• User Stories – A user story is a natural language description, or set of descriptions that describe a specific step that needs to be developed within the scope of a specific feature.
• Bugs – A bug is an error, flaw or failure in the application that causes it to produce an incorrect or unexpected result.
• Technical Work and Maintenance – This refers to the inherent maintenance involved in maintaining integrations with third party code, updates required for various aspects of the product such as security, browsers, operating system updates, integrations and patches.

This important aspect of software development is very often overlooked and has to be maintained in an “underground” fashion by conscientious and dedicated team members.

• Knowledge Acquisition – The integral learning and constant study required to keep up to date and in with the latest technological innovations and updates.

Tips and Tricks for Ordering and Grooming your Backlog

The following section provides some useful pointer and tips to help you organise, arrange and groom your product items in your backlog. I have created a five point plan to help you simplify and focus your backlog creation and grooming.

1) The top items on your product backlog should represent your next sprint.

Arrange your product backlog in a priority numbered list. Assess the individual feartures and allot them an effort score. The effort score refers to the amount of time you think it will take to complete each feature, it’s subordinate user stories and related tasks.

At the beginning it’s more important to give rough estimates rather than trying to be perfect. Each developer on your team takes different amounts of time to complete their assigned tasks, these estimates can be refined for each task over time. This refinement process is how you learn the real amount of time the features/user stories/tasks actually take.

2) Keep your product backlog lean and realistic by putting lower level tasks in a separate list.

The product backlog should be focused, lean and realistic. It should contain the tasks that you need to complete for your next sprint, and all the second-level priority items that you aim to complete within the next few months. Keep it simple…

3) Create a separate list for lower priority items.

It’s important to keep an accurate record of all of your upcoming tasks, but you should make sure that the backlog remain lean and focused. All additional lower priority tasks should therefore be kept separately on a dedicated list that you can draw from overtime adding them to future sprints when they become relevant.

4) Assign time and development resource values to all tasks.

When prioritising your backlog it’s important to define how long each task will take to complete. Assign the number of developers required for each task, which specific developers will do the task and how long it will take them to complete it.

Remember to look at the big picture when estimating how many hours a task will take. It’s always better to overestimate than underestimate the resources required for completing a specrufcu task, but don’t exaggerate either.

5) Re-evaluate the priority of the tasks in your backlog regularly.

The product backlog is a living and dynamic organism, so priorities should change often. As tasks are completed they often give birth to new and additional tasks, that’s a good thing. Although, you should be able to foresee or predict your products food chain as your product advances and you gain more knowledge and experience.

Conclusion

I hope that I have helped you better understand how to create, maintain and groom your product backlog.

I know that when working as part of a dynamic team of highly intelligent people that know what needs to be done, the backlog can often be a flash point of stress and tension.

Overtime this task become easier to understand and with experience you will get better at it and know how to foresee common tasks that are required for all software product construction.