The product backlog is an organized and structured list of work items that reflect your customer needs in relation to a particular product. The product backlog is used to categorize customer requests and ensure the development team is working on the most important features for your business.
Getting started
Before work begins on a new software release, the product manager needs to organize and categorize the items in the product backlog. For new products this may involve spending time with business stakeholders and documenting their requirements into work items. In the case of an existing product this may involve reviewing the list of known customer requests, bugs (defects) and new features.
Adding features to the product backlog
The product backlog can be made of different types of work items. The following list shows the typical work item types in a product backlog:
- Bugs
- Outstanding technical work (technical debt)
- New features
Bugs are known defects that are found during the development, testing and production use of the system.
Technical debt relates to any technical work that needs to be carried out. It can be code refactoring, work to address performance and scalability issues,upgrading 3rd party components, etc... Technical debt is often not visible to the end user unless it impacts the daily system usage such as performance issues. Outstanding technical work needs to be prioritized and scheduled so there is visibility of it in the work plan and all stakeholders are aware of what the development team is working on.
It can be hard to prioritize purely technical work because, often, users don't see the value in spending time in these kind of tasks, however it is important to prioritize and address any technical debt before they become a real hindrance to the system and/or the development process.
New features are functional items that are not currently available or potential improvements to current functionality. Depending on the size and complexity of the system, I tend to separate new feature requests from improvement requests.
A good product backlog will contain a number of work items of various different types including bugs, new requests, improvement requests and technical debt.
Once you have your product log, the next step is to categorize and prioritize the each work item.
Organizing the product backlog in preparation for a new sprint
The next step is to classify and prioritize your product backlog. A backlog is useless if you cannot find the most important tasks or if you don't have the ability to group items together.
Start by classifying your list into themes that make sense to your project. Themes could be "search", "usability" or anything else that is useful to group work items together.
Classifying work items into these themes will help you to quickly identify all types of work items that relate to a certain function and you may decide to have sprints based on themes.
Once you classified your work items it is time to start prioritizing. I find it easier to set priorities once my backlog is organized into themes, however you may choose to prioritize first and then classify your work items, it is really up to you.
It is very important to involve business stakeholders in the process of setting priorities. At the very least,the product owner needs to be able to set high level priorities for your next set of work. This can be done at the theme level, say the next sprint will be about improving usability issues, or he may contribute by setting the relative priority of work items that will be include in the next release.
In my experience, if your product backlog is logically categorized product owners tend to set priorities at the category level (themes), not for each individual work item. It will be your job as the product manager to set the relative priority of the tasks and confirm the final list with the product owner or business stakeholder.
This may sound like a very segmented and inefficient process, however it is important to ensure that you involve the product owner at this stage of the work so that your priorities are aligned with business priorities and strategies.
Once your backlog is categorized and priorities are set it is time to organize your sprint.
Generating your sprint backlog
Once the team knows what features go into the sprint backlog, the development team decomposes the work items into tasks and get on with the work.
No comments:
Post a Comment