Feature shelf life
So I don’t have a formula for quick and accurate estimates. Just a lot of hard work. Still, here’s a tip for free: anyone asking for a firm delivery date is inherently assuming BDUF. Once you know that, you know where to start your answer.
No disagreements with Jacob here, just want to add shelf life to the reasons your business partner will ask for software delivery dates. There are situations when you will be asked for a delivery date in order to get some sense of the freshness of the feature. This date is actually secondary to the primary goal (design win, show demo, competitive trump, industry announcement, etc.).
There is some absurdity in looking at software features this way. You and I might rightly assume that a brilliant feature is justification in its own right. Rationally, a feature’s implementation velocity should just be a stakeholder decision of how much resource they are willing to commit to its completion. Yet, your biz partner may conclude that if the feature can’t be completed in a particular time frame, then its value goes to zero.
Dealing with this is one is tricky, so use all of the communication techniques and energy that Jacob recommends. The best luck I’ve had with this scenario is to defer the answer to the start of the next development iteration. This forces everyone to prioritize the feature in the context of the backlog. If it really is the highest priority thing to do, then we’re in a position to go deep and scope it right away.
Couldn’t agree with you more. One thing that many developers either don’t realize or tend to ignore is the time-value of any given computer solution. I mean, we can track the large inflection points–after all, we know that delivering Lotus 123 in, say, 2003 is a whole lot different from delivering it before anyone else had a viable spreadsheet money-wise. But it’s hard for us to realize that missing the company distributor showcase can be nearly as devastating for that cool new project you are working on.
Businesses are fully aware of these trade-offs. Part of what I am saying is that developers need to learn them as well. That’s part of the vital communication that we need to learn, and a part of the trust that I’m describing. If a company can trust you to understand the importance of hitting a given time frame, they’re more willing to work with you in figuring out the features and polish that will be acceptable for hitting it. It’s when that communication and trust don’t exist that you run into problems. Which, unfortunately, is the norm rather than the exception I think it should be.
Comment by Jacob — February 1, 2007 @ 9:54 pm