Almost every project I encounter has made a grand effort of sorting the system's requirements into various piles based on priority. Perhaps there are piles for High, Medium, and Low priorities. Or perhaps requirements are separated into Mandatory, Desirable, and Optional piles. The Dynamic Systems Development Methodology (DSDM) includes something it calls the "MoSCoW Rules," which derives its name from the categories into which its practitioners sort requirements: Must Have, Should Have, Could Have, and Won't Have.
We use these multi-level prioritization schemes because doing so makes us feel better. When we prioritize something as "optional" we don't feel as though we're telling the customer "no." When we say that a product Could Have a particular feature included in it, we probably believe that it might. We convince ourselves of this even though our personal experience reminds us that on most projects we're happy just to deliver the Must Have requirements.
Unfortunately for our customers and project sponsors, many of them still believe us when we say that a project may include the optional features. After all, the feature isn't "out." It's just optional, which means there's a chance it will be included. However, just as my mom put me off as a young child with a non-committal "We'll see," we all know that a feature relegated to the optional pile is extremely unlikely to be released with the product.
The problem with prioritizing this way is that there is only Now and Not Now. Or, in project terms there is only In and Out. In most situations, there is no point in prioritizing work in any more detail than "here is what we'll work on now" and "that is what we won't work on now." To prioritize at a finer level or in more detail is to forego opportunities to adjust plans and priorities based on what we learn during the project. What the team learns in February may affect what should be worked on in July and August. If that's the case, why plan those months in January?
Since every day on a project affords opportunities to acquire new knowledge, the better we can take advantage of that new knowledge, the better our projects will be. Sixty years ago Nobel laureate F. A. von Hayek wrote about the importance of the use of knowledge. He wrote, "If we possess all the relevant information, if we can start out from a given system of preferences, and if we command complete knowledge of available means, the problem which remains is purely one of logic." Hayek was addressing a different planning problem but his argument remains valid.
When undertaking a software project we suffer from each of the problems Hayek identified:
- We do not possess all relevant information. We are often missing critical information about the domain, about the technology we will be using, about how well team members will work together, about specifically what it is that we are building, and so on.
- We cannot start from a given set of preferences. We often know remarkably little about the true preferences of our prospective customers and users.
- We do not have complete knowledge of available means. We do not know how productive each developer will be. We do not know the quality level each will attain. And we do not know to what extent (if any) the team will gel and individuals will transcend their normal levels of performance.
As Hayek says, if not for those problems, the challenge of planning could be reduced to purely one of logic. Because our knowledge is imperfect, knowledge and learning play important roles in how successful projects satisfy their customers and users. When a decision can be deferred without hurting a project, we should do so. The decision should be deferred until we have learned more so that we avoid making a mistake. A few years ago I was involved in a project that rushed to make a decision about its user interface. We knew we needed to make a decision someday and thought today might as well be the day. We discussed the issue too briefly and decided that a browser-based application would be best. Were we ever wrong! The details of the situation aren't important except that we could have easily deferred that decision while gathering additional marketing information that might have saved us from making a mistake.
The knowledge we can gain on a project comes in two forms: knowledge about the product and knowledge about the project. Knowledge about the product provides insight into what the product should be, the features it should include (or not include), the likely customers and users, when the product should be released, the price of the product, and so on. We gain this type of knowledge by involving users in discussions about features, by frequently demonstrating the latest changes, by refining the product in small increments and getting feedback, by letting users get their hands on working software as often as they'll take it from us, and other similar techniques.
Knowledge about the project educates us about our technology choices, how well our engineering practices are working, the quality level of the code being produced, how individual team members are meshing, our rate of progress through the list of desired functionality, and more. We get this type of knowledge by working in short iterations with frequent deliverables, targeting frequent zero-defect milestones and seeing what it takes to meet them, by examining and measuring the team’s progress, and by observing how well team members collaborate.
Without these areas of knowledge we cannot possibly hope to prioritize work in any meaningful manner. And because this knowledge is created while the project progresses we should defer any decisions that can be deferred until we know more. In fact, the amount of learning that will be generated by developing a feature needs to be an important factor in determining the priority of developing that feature.
There has long been debate about whether projects should prioritize based on risk (as advocated by Barry Above's spiral model) or based on immediate value to the organization, which Tom Gilb referred to as the "juicy bits." There is no single winning factor in that debate. Both risk and value to the organization are important. However, to risk and business value we also need to add the amount and significance of new knowledge that will be generated by developing a particular feature. Only by considering all three dimensions can project teams make proper prioritization and sequencing decisions.
