- Product Backlog
- Sprint Backlog
- Increment (Potentially Shippable –)
Product Backlog holds desirements
It is often said that the Product Backlog must capture all requirements. However, the Product Backlog is not a replacement for the old requirements list. This would limit it to a new name for an old habit. The value of the Product Backlog lies not in precision, in detail or in perfection, like the requirements lists pretended.
The Product Backlog is an ordered list of ideas, features and options to bring an envisioned software product to life or sustain and grow it. The list may include fixes, maintenance work, architectural work, or requirements for security, scalability, stability and performance. Each item on the Product Backlog seems at some point in time valuable for a customer. Every item on the Product Backlog holds just enough detail to make clear what it represents, but the item is also intentionally incomplete to invoke additional and explicit conversation over it. Even the definition of ‘just enough’ varies over time; items on the Product Backlog that are far away in time (ordered low) need even less detail than items that are nearby in time (ordered high).
I like the term ‘desirement’ for a Product Backlog item. The level of description and detail of the item lies somewhere between what used to be a desire and what used to be a requirement; where a ‘desire’ is too fuzzy to work on and a requirement is over-specified and over-detailed. And over-specification impedes an optimal use of technology, blocks capitalizing on synergies between different functions and is a waste of money in situations of even minimal turbulence or change.
As life progresses and the earth keeps turning, Product Backlog in Scrum gets refined, adjusted and updated. The list is continuously sorted and re-sorted by the Product Owner, who thereby looks to balance the needs of all stakeholders. And by continuously keeping to ‘just enough’ descriptions and designs of the work, i.e. leaving out unnecessary details, no excessive money and time is wasted when the item in the end doesn’t get created or is implemented in a different fashion.
Product Backlog is all the plan you need
Desirements move upon their ordering from Product Backlog via Sprint Backlog into Increments of working software. To know their cost, each is assigned an idea of the effort to get it done. The cost is generally expressed as the relative size of the item. Based upon the empirical past that showed how much work on average could be transformed into a working Increment during a Sprint, an expectation can be created on when an item on the Product Backlog might become available in the evolving product. It gives predictability, yet not transgressing into predictions given that any such expectation is constrained by today’s knowledge and circumstances.
- In a traditional plan all requirements are gathered, listed, described, analyzed, estimated and decomposed upfront. All tasks for all requirements are elaborated, sequenced and resource-wise assigned. This way the total time is determined it will take to build the plan, where ‘follow the plan’ determines the success. Dependencies are handled via the detailed tasks, their sequence and their mutual impact.
- In the ‘just enough’ approach of Scrum however, there is no need to plan all tasks for all ‘requirements’ upfront. Desirements are gradually discovered and refined, and they are only converted into development work when included in a forecast for a particular Sprint. The forecast is based upon the relative size indication and the past progress.
Product Backlog is all the plan you need, its desirements hold all the information needed for predictability about scope and time (if that’s what you need).
There is value in value
Priorities in traditional approaches are, besides ease of work and loudmouths, mostly based upon effort and risk. This is a focus on the internal process.
An important principle of agile however is “to satisfy the customer through early and continuous delivery of valuable software.” While the ordering of Product Backlog items happens upon a complex combination of factors like dependencies, priority, cohesion and consistency, most interesting is the required addition of a notion of (Business) Value. Without it, a Product Owner has no idea on how much value a feature, an idea or a feature set presumably brings to the customer whom he/she represents to the Scrum Team. The value can be indirect, in it that not picking up a Product Backlog item might undercut the value of the system or even the organization, or produce negative value.
The notion of (Business) Value also helps Product Owners and their stakeholders move away from the (false idea of) perfection of a total product that must be completely built before releasing. Focus shifts to a minimal marketable product release, the minimal work it takes to bring as much value as possible as soon as possible to the marketplace. Techniques like leveling up can be used to group Product Backlog items into cohesive feature sets.
The value of the Product Backlog
Above all, the value of the Product Backlog lies in transparency, in making clear what work needs to be done in order to create a minimally viable and valuable product (or product Increment). The Product Backlog brings out in the open all work, development, compliances, and constraints that the team has to deal with to create releasable software.
However, too often (and especially in traditional software development environments) the sequence of implementation is based upon priorities like MoSCoW, thus leading to opaque, large clusters of requirements, loss of focus and heavy releases. Therefore, to build valuable stuff, there is value in defining, considering and adding value to Product Backlog items. A Product Backlog item needs the right attributes to be ordered, more than just prioritized.