#NoEstimates movement
The options or methods recommended in agile environments with respect to estimation are:
Estimate in abstract story points
Completely unlink time by freeing it from pressure using story points. It’s not about figuring out how long it will take to develop a user story or knowing its exact scope, but simply knowing the approximate size “a priori”, to intuit how much relative effort the team should apply.
Source: Agile Concepts: Estimating and Planning Poker
A good metaphor is planning a trip. How long will it take us to get there? Why do we use Story Points to estimate and not hours?: The distance to travel is the same for everyone, but we don’t know the exact time it will take us. These story points are represented with the Fibonacci sequence using the planning pocker technique to avoid influences between team members and many other advantages.
Team consensus is much easier and more relaxed. Thus fostering dialogue and continuous learning in the team.
The most outstanding advantages that metrics will provide us through story points are:
- Have an approximate development “cruising speed” allowing for greater approximation with the user stories that the team is going to commit to developing in the sprint.
- Establish a better and more realistic sprint goal and a margin or “buffer” to contemplate technical debts, unforeseen events or other situations.
- Reflect in burn-down or burn-up graphs.
- Source of information for possible improvements in team retrospectives.
- Anticipate/organize pair programming or other collaboration techniques.
- Detect those user stories that do not follow the INVEST principles. In the vast majority of cases: with excessive size (it must be divided) or with dependencies (it must be rethought).
- Perfect indicator for product owners and stakeholders.
Estimate by sizes (XS, S, M, L, XL, XXL)
It gives us all the advantages of story points, except the metrics (values can be related and have them, in which case it would be more advisable to use story points). Planning pocker is also used.
#NoEstimates movement
Led by Woody Zuill and Neil Killick: estimating is not necessary.
Recommended readings
So, do we estimate?
In my opinion, it depends on the level of “maturity” and cohesion of the team and its evolution.
The team has sufficient and necessary knowledge that allows them, based on the repetition of similar cases over time, not to need estimation, since it is implicit and acquired knowledge in the team.
When an agile framework is implemented in an organization or for the first time a team starts its first sprint, I advise that the change be based on the theoretical model proposed by said framework. Without any pre-established adaptation. Avoiding the assumptions and recommendations of third parties, since what may work for one team may not work for another. In the retrospectives, in a natural and personalized way, proposals, decisions and practices will be born in the team to improve their way of working.
So initially, my recommendation is to start with estimation in story points using the Fibonacci sequence through planning pocker.
Over time, learning, maturity and the skill/experience learned and shared, the team will naturally decide that it no longer needs metrics because it knows its intrinsic way of working or organizing: thus simplifying estimation by sizes. Later on, very likely, join the #NoEstimates movement. It all depends on the moment the team is in.
In my opinion, estimation is the perfect learning and maturity path to stop using it.