Variations:
- A Product Plan and a Backlog are pretty much the same.
- Upfront backlog creation
- Static Product Backlog
- Before we start development, we need a complete Product Backlog
- Estimate ALL the items!
Category: General Scrum myths
Danger: Moderate
The basis of the myth
This stems from classic project thinking. The idea is that it is possible to know upfront exactly what the final product will look like. Projects and their tenders are typically defined with a fixed scope upfront. This is simply projected into agile development. Project managers turned into product owner or project teams turned Scrum team without clear understanding of the new way of working will simply turn their Project Plan into a Backlog 1:1.Why is it a myth?
The Scrum guide literally states, "The Product Backlog is an ordered list of everything that might be needed in the product ..." - which is then interpreted as "comprehensive". But, read further. It also states the following: "A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful."Assumption #1: Scope is fixed.
How often is that true? Classic projects always have a "Change Management" process, where changes to original scope are negotiated, usually with an impact to cost or delivery date. Wasteful meetings are introduced to renegotiate these things in order to stay in TQB, leeching capacity without providing any customer value. Feedback learning implies that the Backlog can't be comprehensive.
Assumption #2: We know what is wanted & how it's wanted
There is also a connection to the Sprint Review: The Review is a feedback cycle to inspect+adapt the product development, therefore the Backlog. Any output from the Review is an input into the Backlog and will result in changes to the Backlog. A Review with no output is dysfunctional.
Assumption #3: The world doesn't turn
Comprehensive backlogs assume that new information has no influence on the backlog. Not only learning, but also changes to the world around us will impact existing backlog items. For example, a feature X is no longer relevant, because customers already have another product for that - or we need integration with new product Y on the market to create optimal value for our product. All of these will affect the product.Assumption #4: Long lists are workable
Having a comprehensive backlog means that the backlog will be very long. However, as the size of a list increases, the amount of coordination effort to keep it updated increases. For example, keeping a list of 10 items in order just requires a few minutes.
When we permit 1 second per decision, a backlog with 500 items would take roughly 10 days to fully arrange just once, much less keep up to date. When would the PO spend time with customers or the team? The backlog will become untidy and lose it's value.
Assumption #5: Devil-may-care
Project thinking typically implies that a shipment goes out on a specific date X, and then our responsibility ends. A comprehensive backlog stems from exactly that kind of thinking: "It's done when everything is finished". When a team has responsibility not only to meet some arbitrary deadline, but to make a product successful, there is no definite end date.
As soon as the customer has something in their hand, they need something else. Updates are required to keep an ongoing cash flow. The amount of updates required to maintain an infinite cash flow are infinite, and this would imply that a "comprehensive backlog" would need to be infinite.
When we permit 1 second per decision, a backlog with 500 items would take roughly 10 days to fully arrange just once, much less keep up to date. When would the PO spend time with customers or the team? The backlog will become untidy and lose it's value.
Assumption #5: Devil-may-care
Project thinking typically implies that a shipment goes out on a specific date X, and then our responsibility ends. A comprehensive backlog stems from exactly that kind of thinking: "It's done when everything is finished". When a team has responsibility not only to meet some arbitrary deadline, but to make a product successful, there is no definite end date.
As soon as the customer has something in their hand, they need something else. Updates are required to keep an ongoing cash flow. The amount of updates required to maintain an infinite cash flow are infinite, and this would imply that a "comprehensive backlog" would need to be infinite.
Consequences
With increasing size of the backlog, CRUFT increases. Basically, CRUFT is a measurement of how much % of a given document is waste. This means that increasing backlog size reduces the value of the Backlog. A comprehensive backlog most likely has extremely high CRUFT, so it induces tremendous waste to the Product Owner and development team.
Mindset
A comprehensive backlog will quickly turn sour when an important customer need is not reflected in a backlog item. The "change request" battle continues, which is in stark contrast to the Agile Principle of Welcome change.
Mood
Mood
When the backlog is comprehensive, stakeholders finding their items on the bottom of the backlog will become dissatisfied and may exercise pressure on the team. This, in turn, will dissatisfy the developers and the mood turns sour.
Lost opportunities
Comprehensive backlogs are not intended to evolve. The accompanying reluctance to change makes it difficult for the teams to maximize customer value, and therefore, business opportunities.
Remedies
Capping
The simplest remedy is a backlog size cap. For example, when a team can deliver 5 PBI's per Sprint, a cap of 50 provides nearly half a year of planning horizon. Any item that won't be done within half a year is probably not important enough to warrant any further consideration. When a newly added item would break the cap, an item that is less important than the new item will be discarded.
Filtering
Backlog items should fall into one of the three categories: "Coming soon" (and be refined to put into one of the next Sprints), "On the horizon" (no further effort invested at this time) and "Scrap" (ain't nobody got no time fo' that). Category 3 should be removed from the backlog.
Mindset change
The simplest remedy is a backlog size cap. For example, when a team can deliver 5 PBI's per Sprint, a cap of 50 provides nearly half a year of planning horizon. Any item that won't be done within half a year is probably not important enough to warrant any further consideration. When a newly added item would break the cap, an item that is less important than the new item will be discarded.
Filtering
Backlog items should fall into one of the three categories: "Coming soon" (and be refined to put into one of the next Sprints), "On the horizon" (no further effort invested at this time) and "Scrap" (ain't nobody got no time fo' that). Category 3 should be removed from the backlog.
Mindset change
Both Product Owner and other stakeholders need to be aware that having fewer items in the Product Backlog actually increases the chance that something which is currently not in the Backlog will be delivered in the future.
Team members should understand that the backlog purposefully limits the planning horizon to increase focus on what is and will be worked on. The Scrum master should help the team realize the benefits of this increased focus by spending more time on things that are actually important.
No comments:
Post a Comment