New Product Planning

http://tech.groups.yahoo.com/group/scrumdevelopment/message/56070 by Ron

Now, at this point, there is one question that we might have where we think cost estimates might help us. We're thinking of doing some new thing, and we need to decide whether to invest in it. Owing to some strange reason that I can't imagine, we have no idea at all whether it would cost us a million dollars (one Scrum team for one year), or ten million, or a hundred million. So what should we do in that case?

Well, what we shouldn't do is write up some big list of stories and estimate them. Instead, we should write down about five important things the product has to do, and estimate those. We should estimate those in terms like "how long would it take one Scrum team to do these?" We should use the real product owner and the real team to do this. If, for any of those five things, they really can't guess, we should break that thing down into about five sub-things, and estimate again. (I would probably not expect to go to a third level, but maybe it could happen.) More likely, we'd be looking at no more than 25 still vague product capabilities, and a bunch of estimates that add up to less than a team year. If the sum is more than a team year, we really ought to look for a subset of the product. For many companies, a team quarter would be a better upper limit. For the really good ones, less than that.

Then, if we get an answer we like, we should round up the funds and get started doing what Scrum says: Create a product increment every two weeks. Use that product increment to decide what to do next. Inspect and adapt, improving how we go, as we go. Stay alert always for ways to do smaller things with more value, and stay alert for the possibility -- which is still there -- that our estimates are way out of whack. If they are out of whack, we should have the cojones to cancel the project.

All this is what Mike Vizdos and others have been saying, along the edges of this thread, right along. Do the real work, choosing the very most valuable things to do, see how fast you go, make decisions based on what really happens, not what someone imagined would happen at the moment when they knew the least about the project.