Units of Value

Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they need and can articulate that need in a meaningful and comprehensible way; that the customer can describe the value that they want to get from the project when it is complete.

Depending on the methodology, analysts have constructed numerous abstractions to "organize" and "articulate" the value demanded by the customer. We call these "requirements". "features", "stories" – It really doesn't matter what you call them, as long as you recognize that they are the unit of value delivery around which you build your plan.

Your planning methodology (in conjunction with your software development methodology) must describe a way to turn these units of value into units of work. There are rules and assumptions that must be established about the content and structure of units of value that allow them to be converted into units of work. These assumptions and rule must be understood by analysts and customers who are defining the units of value, and by the technicians that are converting them into units of work. It is these rules and assumptions that allow your plan to accurately describe how you will deliver something of value to your customer, and allow you to communicate your progress towards the goal of that value delivery.

If you want to start somewhere to improve your software projects, start with defining the units of value, and the rules and assumptions necessary to convert them into units of work.

No Comments

Post a Comment