Read on to learn how an agile project prioritization model makes it easier to prioritize and deliverable challenges in a fast-changing environment.
Not all stakeholders are the same in an agile environment. Some are committed while others are only involved.
You may have come across this analogy that compares the stake of a pig and a chicken in making a bacon-and-egg breakfast – the chicken is only involved (in making the egg), but the pig – well, it’s committed.
So, when drawing up a prioritization chart, it’s important to weigh it against the stakeholders – what’s a priority for committed stakeholders matters a lot more than what’s a priority for an involved stakeholder.
A task that’s a high priority for the customer matters a lot more than something the CMO wants.
But here is the thing –
Project tasks do not crop up sequentially in the order of priority.
How do you manage deliverables when a high-priority task crops up when your team is already working on a task that’s relatively lower on the priority scale?
How do you draw up these tasks in the first place?
An agile project prioritization model fixes this.
Agile Projects Prioritization
Agile is primarily an approach towards project management. It emphasizes building incrementally so that your project tasks can be tweaked and revised as you go along.
In agile, the focus is on maximizing outcomes for the committed stakeholder.
But beyond this approach, project teams do not always deploy the agile philosophy towards other aspects of executing the project – including prioritization.
There are, of course, a few popular prioritization models available –
- The MoSCoW Prioritization technique assigns each priority to one of the four buckets – “Must,” “Should,” “Could,” and “Won’t” – and lines them in order.
- The Kano model draws up priorities based on the impact of each priority on customer satisfaction, based on the existence of features, and the degree of implementation.
- The relative weighting model makes use of several different factors like the value of a feature and a scorecard drawn by the product owner to arrive at a priority rank.
While these models have served very well, there is still a lot of subjectivity in how tasks are prioritized.
The product owner, for instance, may not always be the right person to decide the order in which tasks get picked up. Identifying the impact of a feature is, again, pretty subjective. What’s impactful to an involved stakeholder like the CMO is different from what it is to a customer.
Prioritization based on stakeholder priority
So, how do you prioritize tasks based on stakeholder equity? Here is one way to go about this:
To begin with, draw up an extensive list of stakeholders for each project. This should include all the external (customers, suppliers, etc.) and internal (product owner, marketing, finance, etc.) stakeholders.
On a scale of 1 to 100, assign a priority weight to each member. Committed stakeholders draw up a higher priority weight, and people lower in the bureaucratic chain get lower weight.
Generally speaking, the customer would fetch a higher score than the CMO, who, in turn, would score higher than the team’s product marketing specialist.
At the end of each sprint cycle, bring together the list of pending tasks and calculate the weighted average of its impact against the different stakeholders it impacts. The tasks with the highest weighted average are generally the most critical and are taken up in the next sprint cycle.
It’s worth mentioning that this model also has a lot of subjectivity – if you assign a high priority weight to one stakeholder or assign a very low weight to another, this can significantly impact the weighted average.
So, it’s always a good idea to look into reassigning priority weights to the stakeholders after each sprint cycle or at least commit to the change every few cycles.
Setting the project prioritization model in practice
Besides the subjectivity with priority weight, one concern with this model is that some stakeholders are less ‘vocal’ than others. For instance, a CMO might voice their requirement quite strongly to the team. However, a customer-oriented task may seldom crop up in equal measure simply because they do not have a seat at the table.
This model hence relies on your analytics team to serve as a proxy for the customer. Your analytics team may, for example, look exhaustively into customer behaviors – including where they drop off, when they are happy, what makes them frustrated; to identify areas of improvement that are then fed into the operational cycle. Fixes that need to be taken up by the tech team are looped into the project charter to be taken up at the next sprint.
As an advanced version of the model, the prioritization may also take the turnaround time and risk factors for the task into consideration while calculating priority.
For instance, if you want to build an onboarding platform for your suppliers, then you may either integrate each of your supplier data manually into your system or automate the extraction and transformation processes using a next-gen platform. Such modern solutions will enable you to onboard partner data by up to 80 percent faster, from months to minutes. The truth is, while banking on a non-native platform comes with its set of risks, but is also much faster – a good project prioritization model would account for both the turnaround time and the risks to be applied while calculating the priority score for the task versus alternative (building natively, in this case).
Setting the agendas straight
Thanks to these different parameters, one can envision the sprint meetings to be more animated. How much risk factor do you assign to a task? Is a customer really 3x more important than a product owner? There are no easy answers to this, and setting an agenda during your agile meetings can be difficult as all this differs for each team and project.
But having said that, this is a bitter pill to swallow to make the project more outcome-driven and make the entire exercise more worthwhile to your most committed stakeholders. After all, in case of failure, the committed stakeholders do have a lot more to lose than those who are only involved.
