Estimation in Discovery Phase
The process of ideating and developing products (including software products) falls within the domain of Complex Systems. A complex system is a dynamic network of interactions, where the behaviour of the system as a whole may not be predictable based on the behaviour of its component. A model such as the Cynefin Framework which was developed by David Snowden has helped with our understanding of complexity and our approach to addressing complex real world problems.
There are several Agile Frameworks and Practices used within Software Development & Design that help with solving complex (adaptive) problems e.g Discovery process; and sometimes the manner in which these practices are executed seem as though the very nature of Software development is forgotten or undermined..
Agile Framework and Agile Practices attempt to solve complex adaptive problems by optimising for Value using one of more of these principles:
- Promote the use of experiments in other to Understand the problem.
- Provide transparency to the process and the outcome.
- Encourage Feedback as a critical path to Learning.
The Discovery process is a good example of an Agile Practice that helps with managing the complexity of Software Development and the purpose of Discovery is to established a shared understanding at the current point in time. I mention current point in time as the understanding would continually evolve over time and the goal of discovery is to understand enough in other to proceed. Cynefin describes an approach of “Probe - Sense - Respond” for complex problems which ties back to the purpose for Discovery. There are a number activities that are deployed during discovery and these include: Research, Prototyping and User walkthroughs. It is important that a multi-disciplinary team including User Experience Designers, Technical Authority and representatives of the Business & Users be involved in the Discovery phase.
A successful Discovery would lead to some or all of these outcomes:
- Shared Understanding of the product vision.
- Understanding of the User personas, User journeys ands use cases.
- Exploration of potential features and a shared understand of High Level Features.
- Establish working agreement within the technical team and with the business team.
- Decisions about technologies that would be used in development.
The purpose of Discovery is not to entirely eliminate uncertainty but to do enough exploration of the product at a very high level to check if its worth building the product. I am inclined to think that there is a certain amount of uncertainty that is required to be creative especially with complex problems.
In addition, there is a desire for the business (client) to understand how big the problem is and leads to a requests for estimates. Estimates are provided in one of these flavours in the Software development Industry:
Absolute Estimates:
These are estimates that are provided in Man-days and the development process is kicked off using the estimate as basis for budgets. However, with the sheer amount of uncertainty and unknown with a complex problem, absolute estimates are unrealistic and should NOT be provided as an outcome from a Discovery process. The team just doesn’t know enough to provide absolute estimates; providing estimates in man-day sets up the team for “failure” from the initiation of the project because the business track the spends against the budget that it has created using estimates as a basis.
Relative Estimate:
On the other hand relative estimation is provided in Story Points or T-shirt Sizing which is achieved by comparing the size and complexity of one feature relative to another feature. The development team provides relative estimate using intuition considering information that is provided at the current time. Since this form of estimation is not expressed in any unit of time, there is an explicit expression that estimate values remains an estimate and the business is able to make a value vs effort decisions without holding the development team to any form of commitments.
I think that Organisations prefer absolute estimates because as humans we are more comfortable with certainty and a belief (albeit false) that we have eliminated “unknowns” completely. However, the question that comes to mind is, if we agree that there will be unknowns and that the nature of a complex problem changes as we attempt to solve that problem, how sure can we be about absolute estimates?
Relative estimates takes in to account uncertainty and experience of the development team; the nature of relative estimates makes explicit the fact that we do NOT know how long it will take to build a feature. As the team gains more experience with the product and more unknowns removed, future estimates will reflect the experiences that has been gained and also incorporate other constraints such as team, tools and diverse experience within the team.
You Might Also Like
