In the old waterfall days, we'd spend months, sometimes years, developing something only to have our "customers" (marketing and sales) say "That's not what I wanted! I can't sell it!" With agile, those days can be gone. Delivering market-ready business value in each iteration gives corporate leaders the decision point to either:

• Go to market--the project has generated sufficient market value.
• Continue the iterations--the project is producing value at a high rate in each iteration, what I call "business value velocity," but more value is needed.
• Stop the project--going forward it will not generate additional business value. In other words, the business value velocity is too low.

Developers and the companies they work for are faced with grim statistics from the Standish Group: 64 percent of software features are rarely or never used. Yikes! As an executive, I would not be happy if I paid for features that generate little or zero business value. Rapidly moving target windows tell us to develop features with the maximum business value first. Our customers can help us decide what they need most if they are clear on what their business value is for the features they request.

In other words, develop the right things and don't develop the wrong things. Simple? Well, not quite. How can we get a sense of what the right and wrong things are so the entire project team can evaluate which features should be implemented when and not make it too complicated a process?

Determining the business value of a project, iteration, or feature can be difficult. (I am not going to put my toe too far into that field of landmines.) But in my agile work, I have found that it is important to know the purpose of the project and its tie to the company's strategy--something agile-like (incorporates change) and simple to use (lightweight). I use a tool called the Process Purpose Model to determine the purpose of the project (and features) based on whether the project will differentiate us in the marketplace or whether the project needs to get or keep us to parity in the marketplace. If the purpose of the project is differentiation, we treat the features accordingly, collaborating with the customer to develop a market winner. For projects that get or keep us at parity (such as creating an internal benefits-tracking system), we make sure that we do not design or develop something that is better than it needs to be.

Collaborate with your teams, customers, and product owners to decide the purpose of the project and how each feature achieves that purpose. Scrutinize each feature carefully for its contribution to the value proposition of the project. Revisit the value of each feature when you prioritize the backlog. And ask your customers and stakeholders about their differentiators for their marketplace, aligning the project with their corporate strategy, as well.

To help in this process, imagine someone has given your company a free billboard on your local freeway (not totally environmentally sound, but a good marketing opportunity). Would you write, "Buy books from us because we have the best accounting system in the world"? Think about what you would write. That would be what differentiates you in your marketplace. Focus your creative development efforts there.

In the effort to do the right stuff and not the wrong stuff, everyone on the team needs to understand the strategy and purpose of the project to ensure they will raise a flag when they see a feature that does not fit and therefore does not need to be implemented. How many of your testers (the gatekeepers of the "test first" agile process) understand the purpose and how it fits with your company's strategy? If they don't, you may have "feature creep" that may well result in developing some of those costly features that are rarely or never used.