“Amazing how fire exposes our priorities.” – Sherlock
How do you prioritize your tasks? We know that it’s more efficient to solve the most important tasks first, especially when you are a startup and the pace is super fast. But how do you determine which ones are the most important? (And how do you do that without lighting your project on fire first?)
The Pareto principle states that roughly 80% of the effects come from 20% of the causes. Put differently: 80% of the company’s or project’s benefits come from 20% of the time spent by its staff. In an Agile product development context, the same rule would be something like 80% of the product value comes from 20% of product backlog items. But how can you define what tasks must be included in this “magical 20%”? Getting 20% to contain your most vital tasks means solving the prioritization problem in the most optimal way.
Prioritization is a principle that means “doing the first thing first”. As a process, it means “evaluating a group of items and ranking them in their order of importance or urgency”. Actually, prioritization is our everyday activity. We continuously make choices and direct our activity to some task. Sometimes it is a decision between two tasks: 1) make a call to a potential customer or 2) fill gaps in a regular report. Sometimes it’s prioritization between three tasks: 1) go to a supermarket, 2) have dinner with colleagues or 3) visit a doctor…
But other times, especially in agile software development, we deal with the problem of prioritization of N tasks according to M criteria. Quite a regular situation for a startup company. This is the kind of problem which isn’t solved easily for the human brain and thus needs special solutions.
The prioritization problem
(or why successful products need thoughtful prioritization)
Requirements prioritization in all software development methodologies is considered a vital part of the project, but it is especially critical in Agile software development. When we are talking about some of the Product Owner’s activity in Scrum projects, like “Ordering items in Product Backlog to best achieve goals and missions”, “Show what the Scrum Team will work on next” and “Optimizing the value of the work the Development Team performs”, as described in the Scrum Guide, we are actually talking about backlog prioritization.
All we are trying to do is order backlog items according to their priority. In essence, we are trying to determine the user’s top tasks and order them in that way, while also taking into consideration some other criteria (organize user stories from N-items backlog according to M criteria). For example, to prioritize user stories we could use 5 prioritization criteria, such as the value users place on product vision, urgency, time constraints, technical complexity, and stakeholder preferences. To attain success, projects need to be properly prioritized for both the main project objectives and the specific tasks that will achieve the objectives. So we deal with the prioritization problem on two levels:
Product level: Determine what features of the product could better contribute to achieving the main goals of the project.
Tasks level: Define what pieces of work (user stories or tasks) must be realized, and in what order, during the software product development process.
Sounds pretty self-explanatory so far right? But how do you go about solving the prioritization problem? Here are some techniques you can use.
3 Popular Prioritization Techniques
The 100-Dollar Test (Cumulative Voting)
The 100 dollar test, or cumulative voting, is a pretty simple and straightforward technique (described by Leffingwell and Widrig). First, it’s important to gather stakeholders in a prioritization session and make a list of options to be prioritized. All participants are given a finite amount of imaginary units (usually 100 dollars, points, etc.). Each of them should divide the amount among the given options (user stories, tasks, requirements). After that, you can calculate the total units for each option and order them accordingly.
Priority Poker
Priority poker is a quick and easy design game for prioritizing items. It’s called priority poker because it’s very similar to planning poker (a technique for evaluating the costs of the user stories wildly used in Agile development projects).
Before starting the game, the moderator gathers all the people that need to be involved in the prioritization process, such as stakeholders, product owners, designers, developers, domain experts, and perhaps even users. The moderator will also need to prepare the list of tasks to prioritize and a set of priority cards to provide to each player. The number of cards in this set depends on how many levels of priority are useful to use in this particular case. In some cases, it could be a 5 point scale (e.g. very high priority, high priority, medium priority, low priority, very low priority), a 3 point (e.g. high urgency, medium urgency, low urgency) or even 10 point scale. The number of cards corresponds to the numbers on the scale.
Then, the moderator reads a piece of functionality (user story). Each participant chooses the card that they think is the most appropriate ranking for that task and places the card face down on the table. When all participants have made their choice, all the cards are turned over at the same time. The differences are discussed and the game goes on until the estimates are around the same level.
MoSCoW analysis
MoSCoW analysis is the prioritization technique that is recommended for business analysts in the IIBA BABOK and originating from the DSDM (dynamic software development method). According to this method, a list of requirements or user stories should be categorized into the following 4 groups:
M: Must. Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
S: Should. Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if absolutely necessary.
C: Could. Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
W: Won’t. Represents a requirement that stakeholders have agreed will not be implemented in a given release but may be considered in the future.
After classification into the 4 groups, the requirements are ranked in order of preference within each category.
Benefits and limitations of the 3 requirements prioritization methods
All three prioritization techniques help rank and classify items to achieve a more successful product and become prioritization guru (learn more in Hygger blog). The benefits of these methods lie in the fact that they are based on the expert opinion of the team and are quick and easy to complete. The main assumption, and weakness, of all three, is that it requires the team to have a good familiarity with the product. When the product backlog has a lot of items and the participants have different levels of familiarity with the product features, it would be difficult for them to rank or classify the items. In such a case, their expert evaluations could be very rough (unhelpful) estimates.
Nevertheless, using at least one of the prioritization techniques is much better than to let “fire expose” your priorities, which sometimes may happen when you are, for instance, a startup. Don’t let the fires get your project! Let us know if you have any questions.
Images via Pixabay, Free Images and Freepik.
