✥ ✥ ✥
A Product Backlog Item (PBI) does not define how to arrive at a solution or implementation, or how to deploy the solution.
Scrum enables you to manage risk. A PBI gives the Scrum Team enough information to assess business risk. However, it offers no insight into the risks associated with complex development. Development work is, by nature, emergent. PBIs describe deliverables in business terms, while the Development Team works and estimates in production terms.
The two key elements of risk management are feasibility and time. In order to understand and reduce risk, you must understand the PBI in sufficient detail to have confidence that it is technically feasible, and can reach a state of Done within the Production Episode. Even then, you can’t have 100% confidence in feasibility up-front. Even though you can mitigate most risks during Sprint Planning, you need to accept emergent requirements that arise during the Production Episode itself. We don’t want to handle them in the margins or treat them as second-class citizens. Yet, they are not PBIs in their own right.
You could also reduce risk by taking a feature all the way into implementation; in fact, a good Product Owner might support the team with a working prototype of the feature. However, you take on a large amount of unknown risk by implementing a PBI that is judged only on business criteria. If that top PBI takes four weeks by itself, then nothing else will get done during the Sprint.
Coarse granularity estimates are imprecise, unreliable and unpredictable: you need Small Items to estimate.
You can get more development efficiency by viewing a PBI differently. A PBI entails a collection of complementary tasks that build on teamwork and parallel development. The team could self-organize to get started on it, but it needs some direction. What is to prevent all team members from launching into just one of the five things that need to be done to finish this PBI? If the team is going to swarm on a PBI, they better have talked about it first.
Break down Product Backlog Items into work items and assemble them into a plan called a Sprint Backlog. These work items are called Sprint Backlog Items (SBIs). No Sprint Backlog Item typically should be any larger than can be completed by a single Developer in a single day of work.
✥ ✥ ✥
The Development Team commonly expresses work items as tasks, but they can instead be represented as internal artifacts or by any other breakdown. The Development Team confidence about meeting its Sprint Goal with the work items. All the work items to be completed during the Sprint are composed into a plan called the Sprint Backlog. The Sprint Backlog becomes the Development Team’s view of the product increment development.
The process of design (either during Sprint Planning or during the Sprint) offers insight into the work. This design process reduces risks such as realizing the cost of unknown additional work, or delaying the delivery by finding large chunks of latent work too late into the Sprint. Design clarifies the PBI, and uncovers unknown work.
SBIs can be applied as units of progress measurement during a Production Episode. The Sprint Burndown Chart reflects the progress at the granularity of the work items on the Sprint Backlog. This granularity supports rapid feedback. It also improves the fidelity of estimation by creating Small Items to estimate.
The collection of SBIs is dynamic and changes as we learn more about the product. SBIs can emerge as discovered work (e.g., more design and development is needed) or alternatively can die during the course of a Production Episode. So discuss them at the Daily Scrum and replan the Sprint. New SBIs that have emerged should be assigned Estimation Points by the team and the Sprint Burndown Chart should be updated accordingly.
It is a common practice to write SBIs on sticky notes and put them on a progress board called a Scrum Board. Keep the writing to a minimum: the written text for an SBI should be just enough to remind the Team of the outcome of accumulated work plan discussions to date. Another common practice is to also write the Estimation Points on the sticky note which enables easy updating of the Sprint Burndown Chart when the work item is moved to Done. Teams use sticky notes in all kinds of creative manner (e.g. colors, rotation, adding marks, etc.) to accommodate a good visualization of the status of the Sprint Backlog. There is no prescriptive guidance on this usage: It is up to the Development Team to find out what works best for them.
Picture from: PresenterMedia.com.