Agile estimation issues
Estimating work to be done is no easy feat - in Agile, or in Waterfall methodologies. Despite the unscientific nature of work estimates in both approaches, they are, however, a necessity. Stakeholders need an indication of effort and time from the development team for budgetary and planning reasons - this is unavoidable.
Due to the focused nature of most Agile methodologies, estimating how much work an entire feature list - or list of user stories - can be very difficult and, sometimes, inaccurate. This is especially true when you have a new team with an unknown velocity - or in plain terms, when you don’t yet know how fast or efficiently the team can work because they are untested.
It is worth noting again that both Agile and Waterfall face the same problems when it comes to estimating work. For us, though, the big difference is that Waterfall approaches create an illusion of control and a false sense of confidence. The reason for this illusion is that Waterfall methodologies usually expect you to estimate all the work to be done ahead of starting any actual build work.
This means that you are estimating based on some very big assumptions, and even with an experienced team, this is not very likely to work. Additionally, in Waterfall, the system is designed at a very high level, up front - this leaves little room for unknown unknowns or the need to respond to change. Not only does this make estimating inaccurate, but it also means it’s very easy to miss the nuance and detail in the way the system interacts - and only discover the problem a long way down the line.
While estimating with Agile is just as challenging, in comparison, it gives you far better ways to incorporate and respond to change - addressing and identifying risks early through a short, continuous loop of inspecting, testing and adapting.
The key, then, in Agile is to make these estimates as realistic as possible, and to find a way to make them a true indicator of effort - even if they can’t give you exact numbers.
This is where Agile estimation comes in.
Agile estimation
There are many Agile estimation techniques that use all kinds of relative measurements of size and effort, such as T-shirt sizes, story points, work days, etc. The problem is that these techniques don’t tend to separate effort from technical risk. What that means in real terms is teams over-inflate estimates, giving inaccurate impressions of how much work a certain story or epic really is.
For the purposes of this blog, we will use T-shirt sizing as an example.
T-shirt sizing means the team is asked to give each story on the backlog a size ranging from XS to XL. For example:
- S = 1-3 days
- M = 4-6 days
- L = 7-9 days
Typically - and quite understandably - when you ask a development team to estimate the size of a task where they are less knowledgeable on the technical specifics, they are more likely to inflate their estimates to the larger sizes.
This means that unless the team has a high level of confidence in exactly how to achieve a task, the estimates will be higher than actually needed to complete the task.
You may think that is ok, as it makes up for the time needed to figure out how to accomplish the task. However, it also introduces its own problems.
