Scrum; Effort Based Estimation

In Scrum, there's a saying: "Don't estimate days or hours, estimate the effort it takes to complete a requirement like a true champion!" And let me tell you, there's a good reason for that.

You see, when you estimate in days or hours, it's like trying to catch a unicorn with a lasso made of spaghetti. It's just not gonna work. You'll end up with a mess and no unicorn.

Just think about it, if you estimate a requirement will take 3 days, but little did you know, it's actually a 3-day requirement on a Monday. On a Tuesday, it's a 5-day requirement and on a Friday, it's a 2-day requirement. Who knows what it is on a weekend?

And what about those unexpected events? Like the time when your team member got food poisoning on a Monday and the 3-day requirement turned into a 5-day requirement because no one else knew how to debug the Cobol code?

When estimating by days or hours, there is a tendency to over / underestimate the effort required to complete a requirement. This can lead to unrealistic expectations and a lack of understanding of the true scope of the project. Additionally, estimates based on days or hours can be easily affected by unexpected events, such as sick days or unexpected delays.

That's why in Scrum, we estimate effort instead. This allows for a more accurate understanding of the complexity and difficulty of a requirement. It allows the team to better plan and forecast the project timeline, and to make more informed decisions about the allocation of resources.

In Scrum it’s very common to use a technique called "planning poker" to estimate effort. This allows all team members to participate in the estimation process, and to come to the best decision on the effort required for each requirement. This helps to ensure that the estimates are realistic and that everyone on the team understands the scope of the project.

When we estimate effort, we consider all the complexities and difficulties of a requirement. Different teams may use different units for estimating the effort of a requirement. For example, some teams like to use shirt sizes such as Small Medium, large, etc. While other teams might use Fibonacci or a scrum implementation of it, called ‘Scrumonacci’.?

Many times, we rather guestimate the effort by points rather then by time because you are most likely to be wrong (Over or Under estimating), by using the points we remove the illusion of precision.

The most important benefit of estimating effort in Scrum is that it allows for the measurement of improvement over time. By consistently using the same method of estimation, the team can track their progress and see how their estimates compare to actual results. This information can then be used to improve future estimates and make the team more efficient.

For example, if the team consistently underestimates the effort required for a certain type of requirement, they can identify this problem and adjust their estimates accordingly. Similarly, if the team consistently overestimates the effort required for a certain type of requirement, they can also identify this problem and adjust their estimates accordingly.

Additionally, measuring the improvement when estimating this way, allows the team to identify areas where they need to improve and focus their efforts to make the process more effective.

Overall, estimating effort in Scrum is not only a more accurate way of understanding the complexity of a requirement but also allows for the measurement of improvement over time, which in turn helps the team to identify areas where they need to improve and become more efficient and effective.

One more gold recommendation, after estimating the effort of each requirement, divide each one of them into small committable tasks that can be completed in up to 1 day. In this way you will be able to commit in your daily meeting to a very focused goal.