Product Backlog Items
Product Backlog Items (PBIs) describe the work to be done and form a list of work objectives that are placed and ordered on the Product Backlog. They can take many forms with the most popular being epics, features and user stories.
PBIs are normally taken from the Product Backlog during Sprint Planning and can be broken down further as the Development Team form their Sprint Backlog with consumable items that are testable and can be delivered within the Sprint.
User Stories
User Stories and Epics although not part of the core Scrum framework, they are a very popular form of PBI with Scrum teams and are intended to be conversation reminders, with the name “User Story” relating to how they are used in conversation rather than how they are written.
Tasks
Another form of PBI is a simple task that may only indicate the name of the feature or work item to be built. This very simple approach tends to be used by more mature teams that have learnt to continuously collaborate and communicate with each other to thoroughly understand what is required, and all that is needed is a simple reminder for them to understand the context for the task.
One Tier vs. Two Tier Approaches
After the Sprint Planning has been done there should be a selection of PBIs that have made it onto the Sprint Backlog. They may have been decomposed into smaller PBIs and split into something that is consumable by the team. One approach to take whilst working in a Sprint is a one tier approach, where there is one level of PBIs that form the work objectives to be delivered. This single level of PBIs are worked through during the course of the Sprint and are completed as a whole. Another approach is to use a two tier system, where the PBIs are broken down into PBIs and tasks. Tasks being a sub element of work to complete the PBI. Either system tends to work well with teams and usually depends upon the nature of the work and how comfortable the team are at breaking things down into more granular items.
Key considerations when deciding to use either system:
- One tier works well when each of the PBIs are quite small, e.g. when using Planning Poker sizing and Story Points they may be in a range of 1 to 5 Story Points, with any items larger than this range broken down further into smaller PBIs
- If using large PBIs in a one tier system, each PBI can take a long time to complete with little movement seen on the Sprint Backlog and in the metrics if using a Sprint Burndown chart for example. This can promote a lethargic approach to the Sprint and also obscure the team from inspecting their progress towards the Sprint Goal, as these large tickets don’t seem to be moving.
- Two tier works well for teams that struggle a bit to break the work down and it makes sense for them to have PBIs that represent a work objective and that the tasks indicate the things to be done to achieve the objective. Here, the PBIs are generally at a high level and coarse grained.
- If using metrics such as a burn down chart for example, then if using a one tier system, the burndown metric is based upon the size of the PBIs e.g. Story Points. If using a two tier system, then the burn down metrics would be based upon the sizing of the tasks e.g. hours, (assuming that the tasks are small enough that hours to complete them is appropriate.) The general intention is to provide a level of granularity for the metrics that show smooth curves as small items are completed. If large items are tracked, then this leads to large step changes in the metrics, which are not very helpful for a team to make choices during a Sprint.