"Just tell us when you'll be done with all these requirements" is not how to guide an Agile project, be it Kanban, Scrum, or XP. Not remotely.

As we’ve talked about elsewhere, for example in “A Metric Leading to Agility”, the essence of Agile development is the production of a continuous flow of features. These features need to be “Done-Done”, that is, fit in every regard to be deployed.

The point of doing this is to provide information to the business-side people. A waterfall project provides almost no information, especially since we already knew it was going to be late. An Agile project is incremental: we can see the feature set growing. This is valuable information for the business people.

Unfortunately, it is all too common for companies “doing Agile” to dump a list of features on the team, require the team to estimate them, add up the estimates to get a due date, then demand everything by some earlier date. Everything has a priority of “MUST”, and the business people don’t really get involved.

That’s not how you do it.

XP requires a “Customer”, and Scrum requires a “Product Owner”. This is a business-side person who works full time with the team, and whose job is to ensure the best possible product by any given due date. (Kanban doesn’t care whether you have a Product Owner or not: it’s really a way of keeping track of work and identifying how to improve the flow. But all the Agile teams I know of who are effectively doing Kanban have a Product Owner equivalent.)

Now one thing that a Product Owner thinks about is the “minimum marketable features”, the smallest increment of functionality that has value to the end users on its own. There isn’t much sense to deploying anything smaller than the MMF.  However, there are some things to be aware of.

First of all, “minimum” is probably smaller than you think. Suppose someone calls up and says that your email product would be a lot nicer if you could sort by sender instead of just by date of arrival. You immediately realize that there is a need for sorting by subject as well, and that you should be able to filter the messages based on content, and that you should be able to make all the emails that don’t fit the filter disappear entirely for the convenience of finding the ones the user is looking for. It seems awfully important to be able to add new sorts and filters as you go, and to save them for reuse later …

All too often, the Product Owner picks a big subset of these, declares them to be the Minimum Marketable Feature for this idea, and sets the team loose to build it. She declares that she needs it all, so do the bits in any order you want. Meanwhile, the poor devil who wanted to sort by sender waits and waits and waits …

The user could have gotten value from sorting by sender. That’s closer to the minimum. Now of course “he’ll just ask for more”. He’s supposed to ask for more, and we’re supposed to give him more. That’s the nature of our relationship. Rather than make him wait for months and say “Finally!!!”, let’s give him things he wants every week.

So minimum is smaller than you think. Therefore, the Product Owner needs to get actively engaged in trimming down toward the real minimum … and then selecting the order in which to do the bits.

Why is the order important? Let’s look. Probably the ratio between the value of the most important feature and the least important is at least a factor of ten. Id guess it is more like twenty or even one hundred. I’ve seen some feature ideas that seemed to me to have negative value! So in our product backlog, all cleverly labeled “MUST”, there are a few features worth 100, and probably a bunch worth 50 or 60, and a huge pile worth ten, or two.

Let’s compare three strategies for implementing these features: random order, least valuable first, most valuable first. And somewhere in the middle of all these damn things they want is the deadline. The picture looks like this:

It’s no surprise that doing the things of least value first was a dumb idea. But compare what happens between doing things randomly and doing them with the highest value first. At our rather conservative deadline, we have almost thirty percent more value by going value first! But even more important, we could have delivered in one-third the time with the same value, or in one-half the time with easily twenty-five percent more value.

This is why Agile teams deliver visible features. It’s not so that someone can predict the date, far in the future, when we’ll have everything done. We deliver features so that the Product Owner can deliver more value in far less time. And this is why an Agile team needs a fully-engaged, fully-empowered Product Owner.

If you do anything else, you’re spending twice as much to get to market much later than you could have. Don’t do that. You have been warned.