Creative people with limited resources, such as product managers, developers, CEOs, investors and artists, must choose which items to assess, staff or fund. They compare value, cost, flexibility and risk to make a decision.
Faced with too many options, we choose badly …
The job of product management is choosing. The construction of a product backlog, for example, is choosing which item is most important to finish first, second, etc. Should we pursue this project or that project? Should we deliver this feature or that feature first? Should we target this market or that market? Should we consider first this persona or that?
Product managers can choose better if they have obtained estimates for the risk, the development effort and the opportunity cost of each item. But with many items, the cognitive and financial cost of estimating is high. Once these estimates have been made, the sheer number of items can easily overwhelm human decision-making. Faced with a daunting number of items, product managers often make gut-level bets, rather than reasoned choices. Or they delegate to the boss, a strategy called HiPPO (Highest Paid Person’s Opinion). Or they get very irritable.
Development teams must also choose, when they estimate effort for an item. When teams can choose from any value on a linear scale, they usually take an enormous amount of time to decide whether their estimate should be 19 or 20. And yet, in the greater scheme of things, knowing rough estimates for many items is much more beneficial to the product manager than knowing precise estimates for a few items.
Psychological research shows humans cannot intelligently choose when given too many items. George Miller [mill56] asserts normal humans cannot accurately distinguish the ranking of items beyond at most 7±2 one-dimensional measurements. Beyond this, people start making significant errors. On average, we can distinguish between 6 different tones, 5 different decibel levels and 4 different levels of salty taste. By visual inspection, we can distinguish 10–15 distances, 5–7 two-dimensional sizes, 8 different hues, 5 brightness levels. By feeling a vibration on skin, we can distinguish about 4 intensities, 5 durations and 7 locations. Miller claims these limits, show our “channel capacity” of comprehension and communication is roughly limited to 7±2.
Forces
People with the title “product manager” or “product owner” may not be able to control the number of items being considered. This is especially true in larger companies with multiple product lines. In this case, higher-level people may have to make the choice. It is no stretch to assume that, in most companies, the CEO is actually the “chief product officer”.
Product managers can control the number of choices through “chunking” [chun2014]. A chunk is “a collection of elements having strong associations with one another, but weak associations with elements within other chunks” [gobe2001]. Chunking can reduce the number of choices through aggregation, with techniques like Story Mapping. Or it can increase the number of choices through Breaking Down User Stories.
It is easy to come up with ideas. Product managers can limit the number of choices using a Mission Statement and other constraints, which helps limit ideas to those with organizational synergy.
… Therefore, partition choices into 5 to 9 comparable chunks and choose from the chunks.
If the most important chunk is too big, break it down into 5 to 9 sub-chunks, and choose among the sub-chunks, until the best chunk is a suitable size.
For most product management efforts, market uncertainty is a greater threat than implementation uncertainty. We can reduce market risks by associating items that together solve end-user problems (rather than building a consistent and complete component library, for example). We can then test our market assumptions by rapidly releasing features to a market or market surrogate. [vodd2008]
Product managers should primarily consult users and customers to identify feature sets that resolve their problems, and put them into the same chunk. They should also involve developers to discover which features they can more easily create together. [patt2014]
Product managers should represent chunks of requirements at large and small scales using short, communicative descriptions (which people can easily read) rather than long, sloppily written lists. For example, a [Four-Part User Story] can specify a simple feature, such as automatically identifying a credit card, thusly:
As a customer,
the type of my credit card is automatically determined from the card number,
so I can more rapidly checkout,
and so the retail site gets a higher purchase rate per visit.
It can also represent larger-scale efforts:
As a customer,
I can enter a credit card and shipping address in less than 30 seconds,
so I can more rapidly checkout,
and so shoppers prefer this retail site over competitors.
Or even larger scale efforts:
As a customer,
I can checkout very rapidly and securely, whether I am a new or returning customer,
so I feel more satisfied with my shopping experience,
and so shoppers prefer this retail site over competitors.
Keeping requirement descriptions short is a form of chunking. It helps people reduce cognitive load remembering requirements as they consider the different alternatives.
When estimating, teams should limit choice to at most 7±2 different values. This has led to estimation based on Fibonacci numbers, where the size of an estimate is often restricted to 1, 2, 3, 5, 8, 13, ∞. The advantage of this approach is that precision remains roughly constant, as numbers get larger [cohn2005].
In estimation meetings, team members should be making about 7±2 estimates. A creative way to estimate dozens of items in a short session is [Bulk Estimation]. This is an application of Chunk Before Choosing.
Examples
Resulting Context
The results of Chunk Before Choosing should include Product Backlogs and Roadmaps that show roughly 7±2 items at every magnitude [Product Owner].
Product managers applying this pattern will tend to make large-scale decisions first, then progress gradually into the details. In short, they will explore the Mission, Vision, Roadmap and Backlog Items, in that order. Each of these items should have no more than 7±2 subsidiary items.
Developers applying this pattern will consider the big-picture first. What are the 7±2 most challenging attributes of the desired system, and what gross architectural features must we consider to address those challenges?
One benefit of Chunk Before Choosing is that it exposes the contextual goals of an item (in its containing chunk), and this helps everyone make more consistent decisions, even when specific requirements aren’t documented. Product managers will consider overall business goals when deciding the features to pursue first. Developers will consider the overall architectural goals, when they implement small features, and this helps prevent early development from painting the system into a corner.
A contraindication for this pattern is when organizations choose items to satisfy HiPPO (highest paid person’s opinion), unless, of course, the highest paid person uses chunking. Therefore, attempts to use this pattern may require educating leaders to the value of chunking.
Related Patterns
References
[baum2012] Roy F. Baumeister and John Tierney, Willpower: Rediscovering the Greatest Human Strength, Penguin Books (2012).
[chun2014] Wikipedia, “Chunking (psychology).” 2014.
[cohn2005] Mike Cohn, Agile Estimating and Planning, 2005.
[gobe2001] Gobet, F.; Lane, P.C.R.; Croker, S.; Cheng, P.C.H.; Jones, G.; Oliver, I.; & Pine, J.M. (2001). Chunking mechanisms in human learning. Trends in Cognitive Sciences, 5, 236-243.
[kahn2013] Daniel Kahneman, Thinking Fast and Slow, 2013.
[mill1956] Miller, G. A. (1956). “The magical number seven, plus or minus two: Some limits on our capacity for processing information”. Psychological Review 63 (2): 81–97. doi:10.1037/h0043158. PMID 13310704. http://psychclassics.yorku.ca/Miller/
[patt2014] Jeff Patton, User Story Mapping, O’Reilly Media, 2014.
[vodd2008] Bas Vodde, “Choose Feature Teams over Component Teams for Agility,” InfoQ (2008) http://www.infoq.com/articles/scaling-lean-agile-feature-teams.
Acknowledgements
Author
Dan Greening
