They are all Priority 1.

Imagine you are a product manager (maybe you don’t have to imagine). You are starting a project. You have your feature list; a prioritized list of 10 to 15 high level requirements. You already gave up 20 other features by whittling the feature list to the bare minimum. Priority in this list doesn’t matter. They all are number 1!

Someone has the bright idea to manage the project using Agile techniques. You hear about the scope management techniques. Manage scope, you mean give up more functionality? You get mad. You already made your concessions. The market needs all the features in that list. These guys are looking for a way not to commit. Is this progress?

Agile is not a set of practices to avoid commitment. It is a set of values and practices that are used to manage the risk of delivering a software project. In defacto software project management techniques the development team is often sent back to the estimation board until they come up with the right number. I’ve been there. We all want to have our projects and company succeed. We do our best to shave the schedule and feature set down to meet the desired outcome. When the schedule finally has the right answer we can start working on design and construction. We suspend the thought, at least for a while, that our schedule is a dream.

This behavior is not new. Thucydides, and Athenian aristocrat who lived around 400 BC said this:

Their judgment was based on wishful thinking more than sound calculation of possibilities; for the usual thing among men is, when they want something, they will , without any reflection, leave that to hope, while they will employ the full force of reasoning in rejecting what they find unpalatable.

The Athenians lost the war. Are you setting up to lose yours too? Wishful thinking has led to many failed projects too.

How can we win our battle to deliver our product? We need goals. We need to envision where we are going. We need to plan. But we must manage what we want by figuring out what is possible. Can we calculate of the possibilities?

Agile and extreme programming are made up of techniques for managing the development process to realize our goals. How do you, the product manager get all the most important features by the date? A couple tools in the kit are fine grained scope control, iterative development and progress tracking.

Often the requirements are handed off to engineering as a list of ten high level features, you are leaving it up to the engineers to deliver what they think you are asking for, rather than what you need. They might go off and write a detailed requirements document. Engineers have a tendency to over engineer the solution. What if we could engineer just the right solution given the time and resources we have?

Take those ten high level features and break each one down into five or ten smaller features or stories focusing on what the system needs to do. Now that you have your features broken into smaller pieces you will see that some of the stories are more important than others. You will probably notice that the most important twenty percent of the stories do not just come from the most important of the original ten high level features, but are spread through most if not all the original features.

You can’t live without any of the original ten features, but could you deliver a meaningful product that does not have every one of the fine grained stories? There are also some of the stories that you are not sure even what it means to deliver them? If you are not even sure what it is, how confident can you be with some engineering estimate against an unknown requirement? It’s sounding a bit like wishful thinking.

One thing you could do is not start development until all the requirements are nailed down to enough detail to get an accurate estimate. Wow, how long will that take? Is the desired end date fixed or sliding while the analysis continues. No, it’s fixed of course! Why wait? We’ll never get that time back.

Agile is a risk reduction technique; a concurrent engineering technique. Early in the project we know plenty about some of the stories. By all means, let’s get the engineers working on the parts we know about. In parallel further refine the less known stories.

Estimate all the stories. Work on the ones that give the most value for the effort in the early iterations. Define the other high value stories. Estimate those. Track your progress each iteration. Use the teams execution record to see how much of the value be completed by the due date, and manage the project. If your project is like every other project, unanticipated requirements will get added to the list. Maybe you really can’t deliver the needed functionality on time. Maybe more resources are needed, or more time. Or maybe you’ll see that you can deliver meaningful feature content for all ten original high level features, and some for features you did not even anticipate by the desired date!

---

!commentForm