Whats a theme? A theme is a business process that can later be broken into story cards. For example a theme for a retailer wanting to go online might be “A user can checkout a product on my site”. This theme can be broken into dozens of stories, “Add a product to cart”, “Checkout a product”, “Provide Shipping and Billing Address”, “Provide Billing Information”, “Google Checkout”, “Paypal”, “Visa”, “Mastercard”, “Bill Me Later”, “Save profile”.

Start with a list of themes and arrange them in the order as above. Then start with the mandatory themes and break those down into stories. Stories can then be ordered the exact same way as above. Mike Cohn’s presentation at Agile 2008 explains the way themes can be bucketed really well.

Note: A theme is not the same as an epic. An epic is really a large story. The advantage of this approach is that its very clear which themes are important and which stories within those themes. There is no risk of stories slipping through.

The only valid reason for doing this is to give Business an indication of how much the product is going to cost them. Its for an investment decision and of course the variation in estimates has a huge impact on ROI. What makes it tricky is that an estimate is most accurate when there are no unknowns. Practically this is impossible. The more complex the project, the more unknowns there are.

(for tracking purposes I have seen PMs ask developers to break a story into tasks and then provide estimates for that. This is waste, in my experience)

We can’t hold engineering to a number if we don’t provide sufficient details to them.

If we try to pound this problem to submission we might ask Business to spend months in clearly articulating what they need. The costs associated with this is fairly clear. Every day you spend in pushing your product out to market, is a day you waste in earning revenue, a day you allow a competitor to go a step ahead and a day you spend in not changing your mind.

Its not uncommon to have people spend 6 months and more in trying to nail the requirements down. No technology or tool will help you do this better to the extent that you can make this go away.

My experience is that in most projects that I have been, ROI is not really calculated in detail. Most projects start as a Go and then are scrapped midway. This problem is a different one.

Agile with its iterative development tries to solve this in a multi-pronged approach. If we were to break the project into features and then stories, we might be able to provide a relative estimate (points vs hours) at a high-level and elicit sufficient interest to start. As each iteration goes by, the team’s velocity is measured and can be used to project dates when features can be released.

Business can prioritize features and stories so that they get the biggest bang for their buck. Business can also freely change their minds.

With an experienced, talented, sincere team in place (all three are requirements for agile to work) its a fair assumption that velocity will go up, and that the team will do their best. With the teams I have worked on, the meaning of doing their best is really taking on more work mid-sprint even if they pass their historic velocity numbers. “We need more stories” is beautiful to listen to. You do that a few times and velocity is no longer that important as a metric. Maybe it is for releases, but most definitely not to showcase your excellence.

In terms of effort spent into estimating, you really dont want 7 developers 2 hours every 2 weeks. Thats $3000 at $200 an hour. If you remember that an estimate is not held against a developer, maybe even a couple of them can run through this list on behalf of others.

I am aware of the many reasons for making it more rigorous. I have tried that and I don’t think its worth the effort. I might change my mind, but till then, let me enjoy some lightweight estimation.

In short:

1. Keep it simple (no multipliers) and high-level
2. Like there is no perfect story, there is no perfect estimate
3. An estimate is best used to figure out when the features will release
4. An experienced, talented, sincere team will quell any fears of underwork
5. Historical velocity is the best indicator of future velocity

He says that businesses wont be able to get the talent that gains a firm the productivity they need, but “10 X improvement through re-use”?

Hard to buy that . . .