Not all items in the product backlog will be of the same size and level of detail at the same time (i.e. features / eprics / user stories and tasks). PBIs that we plan to work on soon should be near the top of the backlog, small in size, and very detailed so that they can be worked on in a near-term sprint. PBIs that we won’t work on for some time should be toward the bottom of the backlog, larger in size, and less detailed.
Use Cases / Features are capabilities that your end users will have that they didn’t have before. For example, purchasing items online via your mobile phone would be a feature. Your product roadmap usually consists of feature-level requirements.
Epics are the next stage in breaking down a feature into an actionable requirement. They are a series of actions related to the feature. The ability to purchase an item via your mobile phone from the shopping cart using a credit card would be an epic. It’s smaller than a feature (purchasing an item online), but yet it is bigger than the individual credit card integrations that singularly enable an item to be purchased. We don’t allow requirements larger than epics into a release plan.
User stories are the smallest forms of requirements that can still stand on their own. A user story consists of one action of value or one integration of value. For example, purchasing an item via your mobile phone from the shopping cart using a Visa card would be a user story. Purchasing an item using a MasterCard could be a different integration and thus a different user story. User stories are small enough to add to sprints and begin developing. I go into user stories in detail in the sections that follow.
Tasks are the internal steps needed to implement the user story. During sprint planning, a user story is broken down into tasks. While requirements are things that the end user does, tasks are what the development team does to make the requirement work.
Level of Granularity of Product Backlog Items (PBIs)
The Figure depicts the different layers of requirement decomposition for fitting in to the a series of sprints of the development roadmap
- At the top of this Figure above are the orange, largest bricks. They represent the business goals to be achieved by the system, namely use cases or user features.
- At the next level down are PBIs that are bigger than a single sprint but smaller than a release. Let’s call the PBI at this level epics.
- At the third level, we find PBIs that are sized appropriately for a sprint — they can be completed in days rather than weeks. These items meet the team’s Definition of Ready and can be represented as user stories.
- At the lowest level, these PBIs can optionally to be broken down into tasks from a user stories and delivered by the end of a single iteration.
Product Backlog
The Product Backlog lists any required deliverables. Its contents are ordered by business value. As mentioned above, the most important items are shown at the top of the product backlog so the team knows what to deliver first. Backlog Item priority might change, requirements can be added and removed — thus the Product Backlog is a continuously maintained plan towards a growing business value.
Product Backlog Items
Product Backlog Items (PBIs) are the elements that make up the Product Backlog. Product Backlog Items can range from specifications and requirements, to use cases, epics, User Stories, or even bugs, or time-boxed research tasks.
Sprint Planning Process
Sprint Planning is often needed to be prepared for ensuring that the Product Backlog has been refined to an appropriate level of detail, with estimates and acceptance criteria (this is the purpose of Product Backlog Refinement). If the Product Backlog Items have been analysed and thought through during the product backlog refinement process, in the Sprint Planning meeting top priority Product Backlog items can be well understood and easily selected.
Summary
The goal Product Backlog Refinement process is to get Product Backlog items in a ready state for sprint planning, so that the product backlog items is:
- Clear enough and understandable by everyone in the team
- Small enough to be included in a sprint
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Bahasa Indonesia
Русский