There seems to be a great deal of discussion about whether or not estimates should be created for software projects. The arguments are several and frequently descends to the playground level; however, it seems to distill to a few reasonable points of contest.
Quick and Dirty Summary
Ron Jeffries and Steve McConnell – both industry figures that I hold great respect for – held a discussion recently over estimates. (Edit: Thanks to Henebb for making sense of the ordering!)
The No Estimates viewpoint appears to be summarised as:
- Estimates are often wrong so putting effort into this is wasteful and misleading
- Good teams will slice a story into smaller chunks which are often equivalent size. Thus the need for estimation is negated
- Furthermore, breaking it up and thus allowing lower value stories to be deferred
By contrast, proponents of estimates would state that:
- A skilled team can estimate accurately enough to provide business predictability
- By estimating, we can ensure that features are finished, rather than providing more work that is all half-done
- Estimation aids functions such as finance, planning, etc., allowing budget allocation; cost/benefit analysis; etc to be performed
Looking at the discussions, it feels to me that the benefits that McConnell sees appear to be upfront. Estimates are there to support business decisions and allow project control. Jeffries discusses not estimating at a story level, where a skilled team will reduce the size of stories to something more or less uniform.
What Does a Product Manager Want?
So why does a product manager care about estimation? Surely we just want the scrum team to deliver some business value, ideally each sprint?
Well, it goes deeper than this. Product Managers are entrusted with delivering business value and moving metrics in the right direction. Given two options, we want to know whether one has nasty dependencies or incurs significantly more cost than the other. Similarly, if projects have dependencies, the product manager will want reassurance that these will be delivered in a timely fashion. It’s no good having the product waiting for an overloaded team to complete a component.
In these cases, there will need to be some level of investigation work by the Dev teams so that the likely solutions are sufficiently understood. Whether or not an estimate is provided is of little concern to the Product Manager; what they want is to be equipped to make a decision and for the programme manager to be able to coordinate effort so that product is delivered.
At the scrum level, estimates are a means to an end. They protect a team from taking on too much work and set a reasonable expectation to the product manager of the value that will be delivered. However, do we intrinsically care that one story is an 8-pointer while another is a 5-pointer, if the estimate is reasonably accurate so there are few surprises? What’s more, if the development team can break down the eight point story into one- or two-point equivalents, the product manager will be happier as this is a signal that the team understands the problem well.
There may therefore be a progression in team maturity levels. At the very basic level a team will struggle to estimate stories (“everything’s an 8!”) and will fail to reflect on whether the estimate was realistic in hindsight (self-improvement). As they practise estimating, they will become proficient at investigating what goes into a story. Whether the output is a sliced story or a better-informed estimate is somewhat moot; the value is in the discovery and shared understanding. Different organisations will favour different approaches; personally I haven’t worked with slicing stories but I like the sound of it and would welcome a team reaching the point where this is possible.
What of the wider landscape? As mentioned earlier, estimates can be helpful at the planning level, particularly where dependent resources are shared. However, we need to ensure that these are aligned to genuine business goals and are responsive to environmental shifts, rather than projects reduced to a cost-benefit analysis and pet-project favouritism.
Chris Matts and Tony Grout provide a useful experience report of this process at Skype, using SWAGs (Sweet Wild-Ass Guess) in place of a more formal estimation. Note, however, that the SWAG will be provided by a product owner (not a developer, so as not to commit the developers) with experience and some degree of skill. Despite the approximate nature, this is still an estimate. A weighting is applied over time, to ensure some semblance of reality, but the goal of this exercise is to direct resource to the highest priority resource. And isn’t this the entire point of an estimate for planning? We know roughly what will be delivered and we have an agreed order. Need we spend longer, optimising for precision over accuracy?
It feels that there is room for both approaches, used appropriately. Clearly any large organisations will have dependencies and will need to effectively allocate resources. SWAGs seem to be a practical solution, but I can see that an organisation might find value in a deeper level of estimation.
Estimation can also be good practice for less experienced team members. The exercise of examining a story; making an estimate based on one’s understanding; and then reflecting on that estimate having done the work creates a good feedback loop for learning. Where does complexity lie? What gets overlooked at first glance? Where are the defects hidden?
Beyond this, not estimating also appears to hold great value. If a team can work with the product manager to slice stories into small, easily testable, chunks, estimating becomes moot and the focus is on delivering business value. This is already in being done by development teams; at this level and with an experienced team, why would you go back?
Edit: Of course, Steve McConnell summarises the discussion nicely at this point. He suggests that knowing when to estimate and asking the business are the positions we should take, rather than blindly always / never estimating.