To Estimate or Not to Estimate in an OKR World

Does story estimation and team velocity make sense for outcome driven organizations?

As more organizations move to the Objectives and Key Results (OKR) model and focus on activities that provide value-based results, some agile product teams are beginning to question and debate the value of an enduring and traditional agile practice — story estimation.

The highest priority of any product development team is to satisfy the customer through early and continuous delivery of valuable software. With this priority in mind, many organizations are moving to outcome driven measurements — especially, Objectives and Key Results (OKRs) — which allow companies, teams and individuals to focus on achieving a goal (Objective) and measuring their progress toward that goal through outcomes (Key Results). OKRs are an excellent framework for product teams, as they reinforce focusing on solving problems and providing value, rather than primarily concentrating on product features and enhancements.

Output and Velocity may not be the key metrics for teams

The topic of story estimation often solicits conflicting opinions. On one side, practitioners of some scalable agile models emphasize the importance of velocity, which requires story estimation, as a tool for planning releases and improving team productivity. On the other side, output and velocity are not the key metrics for teams that emphasize outcomes defined in OKRs. While OKRs can still be defined for a team operating within a specific scalable agile model, the argument about the value story estimation provides is magnified — especially for teams that were previously solely outcome focused, but later moved into a scalable agile model-driven division within a company.

Such teams struggle with the dichotomy mentioned above and often leads them to the question — to estimate or not to estimate?

Velocity is intended to measure what teams can get done in the future and under the best of circumstances

There are many reasons why a team should estimate their stories. It helps size an effort, informs sprint planning, provides transparency and determines velocity over time. The predictability of a team’s output can then be measured and help in release planning. Also, the effectiveness of any process improvement a team implements can be measured against an established baseline. For some metric-driven organizations and teams, velocity is a valuable measure to gauge output. With this mindset, velocity validates their work and effort. However, velocity is intended to measure what teams can get done in the future and under the best of circumstances. The problem is teams never have perfect information when they are estimating and planning upcoming work.

As already mentioned, teams in the agile space are moving to outcome-based models over output-based models. The quarterly OKR approach is one such model. The basic premise lies in accepting the idea that a team may need to quickly pivot and long-term planning may not make sense, especially in a rapidly changing world. OKRs are often written in an aggressive manner with fifty percent confidence and not in the traditional way of setting achievable or known targets. Frequent product feedback or user testing results will oftentimes push the team to tweak OKRs within a quarter and potentially scrap some already written backlog items.

Consequently, a seventy percent achievement at the end of a quarter is considered success. OKRs are graded based on outcomes achieved, not on the effort applied. Generally, the concept of estimation and velocity serve as a distraction for teams because of how OKRs are tracked and dynamically changes the way teams work. However, teams often under-estimate time, costs, and risks of solutions while overestimating value.

Organizations are experimenting and exploring better ways to maximize value

Such teams prefer incremental outcomes as the yardstick for their progress, since the number of story points completed in a sprint provides no value. In the end, regardless of the number of features and releases a team develops, if the developed product does not provide value, estimation and velocity are not meaningful.

There are good reasons to estimate, but for organizations moving to an OKR model the practice does not provide the value it previously delivered. As agile teams and organizations experiment and look for better ways to maximize value and reduce non-value activities, more organizations and teams will ask the question “So why even estimate?”

What has your experience been? Has your organization moved to an OKR (or similar) approach, which has your team questioning the purpose of estimating? How are you working through it? Please share your thoughts!