Estimation is fundamentally a “guessing game” but in many environments, it is seen and used to make predictions or commitments as to when something will get done. Even worse, is that many organizations focus very hard on trying to make commitments in the large instead of in the small. It’s been stated many times that product development is the art of creating new recipes. There is so much uncertainty in the large.
I actually believe that estimation is an activity that should be done as infrequently as is possible and when done, should be extremely light-weight. I know this might be a bit controversial, especially for my traditionalists friends, but hear me out. I don’t see estimation as a much of value-add to the product development process in most cases. Estimates in the large ultimately create undue pressure (not challenges) and try to impose order on an inherently complex systems. Unfortunately, we don’t learn and keep trying and keep failing. Einstein had a description for such behavior.
This post is going to look at estimation in the case where a “Fixed Date” is not in place but we need to get a sense of the effort required in order to determine what should be done next or as input into a high-level release plan. A “Fixed Date” means that a solution much be delivered or live by a certain date. In the absence of this constraint, I suggest a completely different approach to estimating. There is a lot of effort (possibly overhead) in planning for a Fixed Date so it must be worth it.
The smaller the work item, the better we generally are at estimating. The smallest work item is usually a “task” and so if you are looking for an accurate estimate that will translates to effort (cost) and schedule (delivery), then a user story/requirement/whatever should be decomposed into all its composite tasks and every single task should be taken into consideration. I have made the mistake in the past of not having every different role explicitly specify and estimate their tasks. For example, instead of having a business analyst, developer and tester estimate the same line item, each role estimate their tasks separately.
However, when beginning a new initiative (such as adding a new module) referred to as “themes” in agile speak and “requirements” in other contexts, the tasks are pretty obscure, so what do you do when you’re required to give an estimate? Well you could go through the process of decomposing down to tasks but as mentioned above, except there is a “Fixed Date” for delivery, I wouldn’t do that. I would start with T-Shirt sizes.
T-Shirt sizing provides an avenue to quickly categorize and classify themes into buckets without expending too much effort. Now these sizes need to tie back to a common unit of measure. In my experience, non-product development folks may not understand things like “story points” (if you are using user stories) and so hours/days may need to be used i.e. develop estimates in the language currently spoken in your environment. I believe in using ranges in estimates given the uncertainty that is product development and to account for the cone of uncertainty. So an example (in hours) that I just used recently could be:
- XS: 1 – 100 hours
- S: 100 – 500 hours
- M: 500 – 1000 hours
- L: 1000 – 2000 hours
- XL: 2000 – 5000 hours
- XXL: 5000 – ?
The key is to use a scale that works in your environment. Maybe all your requirements are smaller i.e. under 1000 hours, then XL would be 1000 – ?. The disadvantage with using hours/days is that most product developers are tempted to want to breakdown themes into tasks in order to provide what they consider “better” estimates. A way to mitigate this, is to find a baseline item to work with, such as previously completed initiative (historical data) or another item within the list of themes for which there is more “confidence” about its estimate. Another key point to emphasize is that we’re just attempting to identify at a high-level how much work we think we have. By no means should concrete plans be made on such estimates.
A question that I often get asked, is ‘who’ do I think should provide these “high-level” estimates, especially on teams with different roles involved. This is a little tricky because different roles bring different perspectives to the table. However, my general answer is that the senior technical people who understand the domain should be the primary estimators at this level and it should ideally be more than 2 people. Leverage the wisdom of the crowd. Use the Wideband Delphi method. When discrete tasks are being estimated, get everyone involved.
Assuming the “cost of delay” for a theme has been determined, the result of the estimation process should help drive the selection of the factor should determine.
What do you think? How do you (if you) estimate large requirements or themes?