Imagine gathering requirements as like fishing. You don’t want to catch every single fish in one haul as the processing of that would mean that some fish would go off. Focus on catching the big fish first by using a wide net, then later you can use a finer net to catch the smaller fish. This is the same with requirements as with the big requirements you can use them to understand the product direction better.
Uses historical data with a statistical sampling method
Output is a range of possible future outcomes with a confidence level on that range
Embraces uncertainty of predicting the future
HOW (3, page 130)
Each person had a deck of cards with the fibonacci numbers on them
Item to be estimated is brought to the table
Everyone pulls the card they think represents the right amount of effort
If everyone is within 2 cards of each other, add them all up, take the average and move on
If people are more than 3 cards apart, the low and high ends talk through their reasons, then everyone does another round
‘take a broad array of opinions, attempts to remove as much biais as possible, and with informed, yet anonymous, statements, narrows down opinions into a generally accepted estimate’ (3, page 129)
Avoids bandwagon effect (everyone jumping on an idea because they thought everyone else was on board) (3, page 125)
Avoids halo-effect (when one characteristic of something influences how people perceive other unrelated characteristics (3, page 126)
Asymmetric nature of software estimation errors (2, page 203)
‘ There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say. We know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know’
Former Secretary of Defence Donal Rumsfield
Estimations are more likely to take longer than expected than they are to take a shorter amount of time than expected (i.e. they are asymmetric)
Developers estimate based on known knowns, and sometimes known unknowns.
Some error comes from misunderstanding these
Most comes from unknown unknowns
Larger tasks are more likely to have more unknown unknowns so the risk of rapidly increasing is much higher
Cone of uncertainty shows that the likeliness of under as over-estimation is symmetric
Existing product problem statement elements (1, page 25)
The current goals of the product or system
The problem the business wants addressed (i.e. where the goals aren’t being met)
An explicit request for improvement that doesn’t dictate a specific solution
[Our service/ product] is intended to achieve [these goals].
We have observed that the product/ service isn't meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [service/ product] so that our customer are more successful based on [these measurable criteria]?
Template (1, page 26)
New product problem statement elements (1, page 27)
The current state of the market
The opportunity the business wants to exploit (i.e. where the current solutions are failing)
A strategic vision for a product or service to address the market gap
The current state of the [domain] has focused primarily on [customer segments, pain points, etc]
Our product/ service will address this gap by [vision/ strategy]
Our initial focus will be [this segment]Template (1, page 27)