Effort estimation is the practice in Agile Development when the team defines how big the task/story/bug is. This information will come in handy when we do sprint or roadmap planning. Some teams might estimate for complexity (not the effort) but they would still use the same method.

Estimation methods

There are various methods of estimation but in this article, we are going to look at the most popular ones.

Story points

This estimation method uses the numbers as unit. When we estimate with story points, we assign a point value to each item. The number sequence may vary from team to team. There are a few options as follows:

• Fibonacci sequence: 1, 2, 3, 5, 8, 13. The reason for this is to clearly distinguish the difference between tickets. Of course, there will not be an exact value for every ticket, but with this sequence, we can differentiate the estimation well enough.
• Doubling sequence: 1, 2, 4, 6, 8, 16. This one is easier to remember but doesn’t have a huge difference between tickets.

T-shirt Sizing

Another method is to use T-shirt sizing. The popular sizes are XXS, XS, S, M, L, XL, XXL. It is using the size of the t-shirt so everyone can easily understand how ‘big’ the ticket is. The purpose of using t-shirt is to get rid of the number, which could be misleading and complicate the estimation process. Sometimes, the 3-story-point ticket doesn’t necessarily 3 times bigger than the 1-story-point ticket.

A simple tool to estimate quickly and correctly

A tool that my team has been using for a while and find very helpful is Planning Poker. In short, it is a way to gamify the estimation process, where the team individually give estimation for the ticket and discuss to reach the consensus. Benefits of Planning Poker:

• Simple and easy to ‘play’. The rule is very straight forward: everyone give their estimation secretly and reveal at the same time, which leads to the second benefit.
• No HIPPO effect (the highest paid person’s opinion). Usually, other people will follow the idea of the leader or their boss. With this tool, they have to give their own opinion.

There are many free website that allow you to set up a Planning Poker game with the team. Let’s give it a try!

Factors affecting the estimation

Complexity

This is the most obvious factor. The more complicated the ticket, the higher the estimation. The complexity will come from many factor:

• Does it require BE support from scratch, or we don’t need BE support at all?
• Do we have this component already or this is a completely new feature?
• This could be a small changes but might hugely affect other part of the product. So does the QA need to regression test everything?
• And many other things that comprise the complexity of the ticket.

Risk and Uncertainty

This refers to the things that we are unsure (i.e. the changes in user’s need, technical conflicts,…) or the dependency on other teams (i.e. we need other teams to support on some implementation). If the ticket has high risk and uncertainty, it is likely to take the team more effort than usual to cope with it.

Based tickets

It’s a fact the human brain is not very good at exact estimation. It is much better at the comparison job. Hence, we need to set some based tickets for each level of estimation. For example, when we talk about 1 story point or the XXS size, the team should know that how that ticket would look like, and what is the exact ticket in the past that we agreed on to deserve that number.

Having a based ticket proves to be very helpful when it comes to uncertainty of which size to choose. We can just simply refer to the old ticket and think if it has the same complexity or not.