agile-process.org Home

Most Important Features First

extremeprogramming.org
How can we help our business grow? It seems like an obvious question for everyone to ask. Yet many software teams never do. When we consider adopting an Agile process we worry about iterations and testing. But the very first thing you must do to become Agile is establish a good relationship with your customers, users, and domain experts; who ever it is that directly or indirectly pays for your work.
The first symptom of a damaged customer relationship is when your customer considers it a waste of time to participate in the project. You may have delivered software that just doesn't meet return on investment (ROI). You may have delivered software that is frustrating to use. You may even have treated the customer with disdain. In any case your customer is important and you need to repair your relationship first.
One way to start a partnership with your customers is to listen to their needs and respond immediately. The best way to guarantee your customer's time (and thus money) isn't wasted is to involve them enough to guarantee success. Customers who don't want to be involved in their own software project believe the software will be built the same even if they don't participate. This belief needs to be dispelled.
Damage to the customer relationship can be the result of careless disdain for the customer's expertise by the development team. It doesn't matter how smart you may think you are, you simply can't expect to know as much as your customer. You can't learn in weeks what someone else learned over years. Respect your customer by acknowledging their expertise, listen carefully, defer to their authority, and never insert your own opinions into your code.
Repairing an abused relationship takes time. Trust takes months to establish but minutes to destroy. Start out by being honest about your process. Everyone will give up something before the project is over. Giving up something first is a good way to start. Give up on having the most interesting and complex system around by
simplifying and listening to customer objectives.
 Communicate with your customers simply and in a language they understand. Most specifications are way too technical for customers to understand. Do you really expect your customer to approve your SQL queries? So where do you draw the line? What is technical by-product and what is requirements? Many Agile projects use stories and face to face daily communication as requirements.
 Agile projects keep a set of unfinished features as stories in a simple spreadsheet, list, or stack of cards that form the backlog of product features. You want to prune or groom this list on a regular basis by removing and destroying things your customer or product owner doesn't need anymore. Only keep features you would consider paying good money for, the rest go into the trash can or shredder.
 From the list of unfinished features you will choose the most important. Important means different things to different teams. You can choose the highest return on investment (ROI). You can choose the architecturally significant features first. Risk is a very important way to sort. You can choose the features in groups that make good business sense together. Most projects settle on a combination. The one constraint is that the customers guided by estimates of effort from developers choose what is most important next.
This collection of most important features is the input to the planning process. Features are represented in a minimal way that allows rough estimates of effort, but not detail. You will probably only implement a fraction of the features, so spending time on details is a waste until they are actually part of an iteration or sprint plan. Many Agile teams use a quick way to scope projects called story cards.
 Stories are the currency of your project. Like money they don't have much value themselves, just a piece of paper, but they represent value and can be used to buy things. Stories represent valuable software to customers,
One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
time to developers, and negotiable increments of scope to managers. Stories without value to the customer are counterfeit. Destroy any stories that have no value. If you find that you can't tear up or delete a story without second thoughts then you are making your stories more valuable than mere currency by spending too much time on them. Use cases can be especially hard to throw away once created unless you limit them to title, estimate, and a brief description at first.
Important project decisions are difficult and stressful. Agile projects distribute the responsibility for decisions amongst the entire team. Developers make technical desicions, managers make people descicions, and customers make business decisions. The best way to ensure bad choices is to have one person make them all.
Spending a million dollars on a software project does not mean you have software worth a million dollars. If your customers think being part of software development is wasteful you might be  building the wrong software. Don't just sort user stories by importance, sort your entire portfolio of potential projects by importance as well.
Once we know what we want to build next we will use iterative planning to stay on track.A Project Heartbeat

One dozen Agile words: Iterative planning, honest plans, project heartbeat, working software, team empowerment, and daily communication.
About the Author

Copyright 2009 Don Wells all rights reserved.


Most Important FirstIterative PlanningA Project HeartbeatHonest PlansTeam EmpowermentDaily CommunicationWorking Software