Scrum is a light-weight framework with a minimal set of rules. The rules help people to empirically make the most out of every single day of creating software products. Next to 3 roles and 5 events, Scrum requires no more than 3 artefacts:
- 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.
5 thoughts on “The Value of the Product Backlog”
[…] 产品Backlog顶部的产品Backlog项目应该进行细化，并且可能很快就会包含在下一个sprint计划中。积压下来的项目需要更少的具体，并且可以反映更大的矿石更复杂的想法。这些较大的块需要在接近Product Backlog的顶部时分解成更小的块，如下图所示，如Gunther Verheyen的文章 – 产品Backlog的价值所示： […]
[…] Product Backlog items at the top of the Product Backlog should be refined and likely to be included soon in next sprint planning. Items further down the backlog need less concrete and can reflect bigger ore more complex ideas. These larger chunks will need to be broken down into smaller pieces as they approach the top of the Product Backlog as shown in the Figure below as suggested by Gunther Verheyen’s article – The Value of the Product Backlog: […]
[…] Backlog is a strategic instrument of high value; for stakeholders, product management, the organization, the Development Team(s), and the Product […]
[…] the Product Backlog as the single plan for one (1) meaningful initiative (project/product/service). Slice the […]
Reblogged this on News & Notes on LEADERSHIP for LEARNING.