Software projects are surrounded by a high level of uncertainty. Even if developers or a consultant gives you a project estimate, until development begins, you won’t know exactly what resources you need to implement the user stories that you’ve planned for your next release.
This, however, is certain: to ensure that your project is a success, you should use prioritization methods, which will help you understand which stories you need to tackle first.
The HiPPO method
The most frequently used prioritization method in the business world is called the HiPPO method. HiPPO stands for Highest Paid Person’s Opinion. And a HiPPO can be a boss, client, or investor. This person is so sure of their vision that they make decisions without consulting others on their team — they and they alone decide what user stories to prioritize.
HiPPOs run the risk of alienating team members and establishing a harmful top-down leadership structure. A HiPPO might prioritize stories that they think are important, even if the stories are out of scope or past deadline, something that other team members could have pointed out to them had they been given the chance to.
You can probably guess that this method limits a team’s ability to work effectively and understand what the organization is doing and why. Luckily, there are more sophisticated prioritization methods that companies can (and should) use instead.
The iron triangle
The iron triangle is a concept that helps project managers make sound decisions. The three “points” on the triangle are 1) time, 2) cost, and 3) scope.
These points are interdependent. So, for example, the bigger the project’s scope, the more time or resources you need to complete it. If you don’t have the necessary time or resources, the quality of the project degrades.
You shouldn’t sacrifice project quality to meet deadlines. Sometimes you can increase your budget, but often, that doesn’t work either — you can’t always just throw money and people at a task and expect it to be completed faster. Sometimes features and user stories just don’t split between developers. The only thing you can really control is scope.
In order to make sure that you meet the release deadline or budget constraints, you have to buckle up and get realistic — cut your scope ruthlessly. The only way to do that with confidence is to prioritize the user stories and features in your backlog.
Prioritizing by value
If you believe that all user stories are equally important, what you’ll end up doing is peanut buttering your efforts across stories without a guarantee that you’ll complete what needs to be done in time for the release. This is why prioritizing stories by value is so important.
We can define the priority of user stories using the MoSCoW method. The term MoSCoW stands for Must-haves, Should-haves, Could-haves, and Won’t-haves. (The Os were added to make the mnemonic pronounceable.)
Management and developers can use these four categories to label the importance of user stories within a release:
Must-haves
Must-have user stories are critical. They need to be implemented in order for the project to be successful. They’re so important that even if one must-have user story is not implemented, the whole project fails. Such stories should describe only a minimal set of functionality that makes them viable.
Should-haves
Like must-haves, should-have user stories need to be implemented for the project to succeed, but are usually less time-critical and can be implemented…later. For example, a password reset can be a should-have user story, but it’s not necessary for the initial release since the support team can reset passwords manually during the first three months.
Could-haves
Could-have user stories improve UX, but they aren’t critical. They’re usually simple upgrades to the application flow, like improving error messages or adjusting what is viewed on a screen on certain devices. Could-haves are typically included in the sprint if there are some story points available, and are easily skipped if something unexpected comes up. More often than not, these will remain in the backlog forever until you decide to implement them.
Won’t-haves
Won’t-have user stories are important, but they have the lowest business value, due to either a low effort-to-value ratio or because management doesn’t recognize the improvements they create. Most of the refactoring, automation, and other development housekeeping stories fall into this category, causing a lot of technical debt if they pile up.
The complexity matrix
“I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.” Dwight D. Eisenhower
While prioritizing by value is helpful, you can make even better decisions by using the complexity matrix. If you’ve ever heard of the Eisenhower Matrix, this should be familiar to you.
The complexity matrix factors story points into the prioritization process. In order to further categorize and prioritize your user stories, you can create a two by two matrix with four boxes, for four types of stories:
- Highly valuable but not complex
- Highly valuable and complex
- Not highly valuable and not complex
- Not highly valuable and complex
By organizing the user stories in these boxes, you can clearly see which stories you need to tackle right away and which ones you probably shouldn’t implement.
The walking skeleton method
Another great approach to prioritizing user stories is creating a walking skeleton story map, as Jeff Patton describes here.
A story map is a way to organize user stories by features. All of the features are arranged as columns, acting like vertebrae, and stories hang down like ribs. This representation allows you to visualize the importance of user stories within certain features and focus on implementing one set of stories at a time.
After you’ve defined the backbone and listed all your main features, you can start prioritizing the stories within each rib. The higher the story is, the closer it is to the backbone, the more important and urgent it is. Stories that are closer to the bottom are less important — kind of like could-haves and won’t-haves.
Once you’ve arranged the stories, you’ll see a minimum implementation of your product at the top of the story map. This is what Alistair Cockburn calls a walking skeleton: a very minimal but working product that is usually ready for user testing.
Originally published at The Startup: Build something awesome