Estimation

The team regards estimation as an essential component of planning and a prerequisite in product development.

The team’s standard estimation process, namely story estimation, follows the Agile methodology.

Learn more about user story estimation

Purpose

Feasibility Assessment

The very first place where estimations are being used is to communicate feasibility. In this regard, estimation is a communication tool.

Internally, this means Team Leads telling the Product Manager “this feature looks straightforward to implement” or inversely, “this feature looks more complex and has significant risks”.

Externally, it means telling the client “here is roughly how long we will need to build this feature; let’s discuss when you’d like to schedule it.” If the client had a specific timeline in mind for the requested feature, the Product Manager can then tell them “it looks like we can make it” or “the feature is just too big, let’s discuss options to either adjust the timeline or increase the team’s capacity.”

Estimating is the first step after a client asks for a new feature or a change. Before kicking off any planning, the team needs to give the client an idea of the feasibility and, if it does not appear feasible, figure out some options that can be shared with the client.

Data-based Planning

Once the client reviewed the feature with the Product Manager and the estimations have been done, it is time for planning.

Product Managers analyze the average number of story points delivered over the past 3-4 sprints. Based on this historical data, Product Managers can then accurately predict the squad’s future delivery capacity. There are variables to factor in, though. The recorded data will only hold if all factors remain equal (e.g., squad size, codebase at play, no last-minute planning changes).

The Product Manager and Engineering Lead are responsible for monitoring the development team’s output. If the team velocity decreases unexpectedly, the Product Manager must coordinate with the Engineering Lead and Team Lead to solve it. Indeed, any significant changes in the team velocity impact the planning accuracy.

Limitations

Bias and Inaccuracy

It has been proven that estimates are always inaccurate and biased depending on who estimates. The team not only accepts this limitation but embraces it. The estimation will likely be close to reality as long as the individual or squad who made the estimation is also the one who will execute the work. Thus, it represents the actual velocity of the individual and the development team over time.

Time Consuming

When executed poorly, estimations can be a time-sink for teams. In addition to producing inaccurate estimates, getting a whole team in a room for an hour or more leads to expensive, inaccurate estimates. Instead, the team could have spent that time on delivering features.

For those reasons, the team does not follow any formal methodology, such as Planning Poker or backlog refinement sessions. The goal is to do it fast while being mindful of the team’s and client’s time (and money).

In conclusion, the key to making estimations useful is to align all parties involved, comprising internally of the Product and Engineering team members and externally of the client stakeholders, with its purposes and limitations. The team’s methodology strives to strike the right balance to reap the most benefits of estimations.