The Myth of "Must Have"

Traditionally, we've categorized requirements as "musts", "shoulds" and "frills". In theory, the musts had to be there to ship. But in reality, many of the musts didn't make it. And unless easy or sexy to the developers, you can forget about the shoulds and frills. So who decides which musts make it? In the absence of someone working with the teams to prioritize things to a finer level, it is determined by the order of attack of development. Those not done yet when things start to look bad get thrown out.

Agile solves this problem by ranking the requirements (typically in the form of stories). If you could only have one thing in the release, what would it be? What if you could have two things? Etc. This ensures that you're attacking the most important things first and that if you come up short, it will be the least important things that get left off.

But isn't there a line that you have to meet in order for the market to accept your release? Maybe. But it is rarely where you think it will be at the start of the release. Every iteration is an opportunity for feedback. Don't assume. Do a little and validate it. Do a little more and validate again.

Start with the thing that you're most sure is necessary. Then learn something from it. What affect does what was learned have on the priorities for the rest of the release? Is that next item still necessary? Is something else needed instead? By looking at the backlog and adjusting it at least once an iteration, you'll get a lot closer to what really needs to be there.

All customers are different. Maybe minimal acceptable for one isn't the same for the others. The further you get down the backlog, the larger applicability the release has to the larger customer population. But, the important point is that if you've done your prioritization right, you don't have to get all the way down to add value. You can release with what you have on the date that you planned. You know it is the most valuable you could have done (given your frequent adjustments). Get it out there and get feedback.

The productivity of agile is due as much to what you don't do as it is to how much more you're able to do. Agressively prioritize and constantly get feedback to make sure you're focused on that which will add the most value.