Agile Sizing and Estimation with Justin Thatil and Mike Guiler

Dan Neumann welcomes Justin Thatil and Mike Guiler to today’s conversation.

 

This week, they are discussing estimation and sizing in an Agile environment. Both estimation and sizing are essential for Agile teams to plan their work, manage expectations, and adapt to changes in a flexible manner. They promote a collaborative approach to understanding the work ahead, fostering team communication, and enabling the team to provide more accurate forecasts without the rigid limitations of fixed time-based estimates. Listen to this episode for actionable tips and examples of how to best estimate and size for the best interest of Organizations and Teams.

 

Key Takeaways

Estimations can be inaccurate sometimes.

Pressure on the Team can cause the estimations not to be good in predicting the costs of a product.

Positivity bias can also influence estimations negatively.

Removing the contingencies does not make the estimation better.

The key to estimating is taking a project, breaking it down into details, estimating the number of hours, and adding them up.

All the sequencing and the dependencies are not considered.

Remember there is a Team working on that project; you can’t take only one member’s speed or ability under consideration, but the idea is to consider the issues the whole Team could confront.

The estimate process needs to be leveled up.

Establish a scale so you can evaluate the size of the project and its proper cost.

Remember to include the contingencies, the unknown.

Human ability to compare can only be achieved accurately when it is done among two known things.

Can story points be represented by hours?

A Team’s data can be normalized to take care of the next estimation.

Example: I am a product owner, how do I determine the cost of a featured leveled backlog? I have to identify a real value.

Add up the Featured Leveled Backlog times the Team Velocity, and that will equal the number of sprints, which will lead to a cost.

Does it need to be faster? Employ more than one Team!

Ask: How much do you want to spend and how quickly do you want to move?

Hours: Are they useful for estimation or, on the contrary, are they misleading?

It depends on the maturity of the Team.

Justin shares an example of a way to discover the average velocity of a Team.

 

Mentioned in this Episode:

Story Points — a mathematical perspective, Salman Ali Banani

Intuitive prediction biases and corrective procedures

Lead without Blame: Building Resilient Learning Teams Diana Larsen and Tricia Broderick.

 

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!