Set expectations
Buyers unfamiliar with product development will often have misconceptions about what an estimate is meant to accomplish and how true iterative delivery works. It is the job of the team to educate the client about the best practices as well as realities of product development. It’s the job of the team to sell our process and set correct expectations.
First, estimates should be used as a budgetary guideline and not as a guarantee that x dollars will deliver y features. Building custom products is inherently loaded with unknowns—any given product is built for the first time, and iterative delivery will lead to new discoveries along the way. An incremental release of, for example, two sprints will invalidate assumptions made about a specific epic in the backlog and the team will need to reprioritize and rerefine the remaining workstream.
Second, the team works to deliver outcomes and business value, not individual features. The workshop may identify a list of features desirable for the product, but user testing and market validation will take precedent any day. This approach leads to better outcomes and higher value delivered as compared to classic project management techniques. In waterfall a team may overengineer a feature set in the product only to discover 30 percent of functionality being actively used by users when the product launches.
Third, unplanned risks will surface and derail the team. It’s inherent in software delivery and practically unavoidable. For example, a team building an online document authoring tool ran into a roadblock when a pagination feature could not be easily implemented using the selected front-end library. It was a very specific edge case and required four times the effort to address. The estimation process will never be able to get granular and deep enough to anticipate these types of risks (for risk of getting into a waterfall requirement workflow).
We are accountable to set budgets and delivering results. Estimates are used as guidelines to make sure the team has room to succeed.
Having said all that, we are still accountable to budgets and delivering results. Pay special care to ship working software on a per-sprint basis and involve stakeholders in the acceptance process, demonstrating results and involving them in the decision-making process. As long as results are delivered, no one will treat estimates as binding contracts for specific feature delivery.
