Design - Prioritisation
Multitasking is the problem, we should focus on one thing at a time
Data teams should only work on one thing at a time, but the problem is they often don’t know what the most important thing is.
Stakeholders know the business outcomes they need to achieve, but they often believe that multiple outcomes need to be delivered at the same time to be successful. For each of these business outcomes they have a raft of ideas on the actions that can be taken to achieve these outcomes. Each of these actions should be supported by multiple bits of data and information.
Given this complexity Stakeholders struggle to identify which bits of data and information are the most important right now, and they know that whatever they prioritise today, is likely to change next week or next month.
We use Prioritisation patterns to solve these problems. They provide a forcing function to help Stakeholders identify what data or information will provide the greatest business value and therefore should be the first thing the AgileData team focuses on delivering. They also enable constant iteration of these priorities so they can change at the same cadence the required business outcomes and actions change. If
The Concept of Prioritisation
Prioritisation is the process of identifying and organising the most important work or goals and then allocating resources (such as time, effort, or money) to them in order of their value or urgency.
The goal of prioritisation is to ensure that the most critical or valuable needs are addressed first and that resources are used efficiently and effectively.
Prioritisation is used in every industry, in every business process, in every thing we do on a daily basis. Sometimes prioritisation is a conscious decision by a person or a group of people but most often prioritisation is something we do unconsciously.
Do we clean our teeth before or after eating breakfast, do we have time for a shower this morning before going to work, do I buy breakfast at a cafe or do I save the money for my planned holiday.
Domain Specific Prioritisation
Prioritisation is a critical process in many domains, and each domain uses different inputs or drivers to evaluate what is the most important thing to work on.
In a construction project, the prioritisation process will involve determining which tasks must be completed first to avoid delays or rework, such as laying the foundation before building the walls.
In a hospital emergency room, the prioritisation process will involve triaging patients based on the severity of their injuries or illnesses, with those in the most critical condition receiving treatment first.
In a manufacturing company, prioritisation will involve determining which product lines to manufacture next based on factors such as customer demand, profit margins, and production capacity.
In software development, prioritisation will involve determining which features to implement first based on the goals of the software, available resources, customer demand, technical feasibility and customer feedback.
In a government agency responsible for road maintenance, prioritisation will involve determining which roads to repair first based on factors such as traffic volume, safety concerns, and the cost of repairs.
In the military, prioritisation will involve prioritising objectives based on the strategic importance of a mission, the urgency of a situation, and the potential consequences of different courses of action.
A person who is prioritising options for upskilling may consider factors such as their personal interests, career goals, market demand for specific skills, and available resources such as time and money.
While the inputs and outputs of this prioritisation is specific to the domain the patterns used to prioritise the work are often common across the domains.
Prioritisation Patterns
There are a number of core patterns that are used for prioritisation and there are also many iterations of how to use these patterns, which are patterns in of themselves.
We can categorise prioritisation patterns into three types, core patterns, fixed mindset patterns and growth mindsets patterns.
Core prioritisation patterns refer to the foundational patterns and techniques that are commonly used to prioritise work, the fixed mindset and growth mindset prioritisation patterns are all variations of these core patterns.
Fixed mindset patterns, refer to prioritisation patterns that are based on a fixed or rigid way of thinking. This approach assumes that priorities are static and that once a decision is made, they are not changed. Examples of fixed mindset patterns include the MoSCoW pattern, Kano pattern, value-driven prioritisation, and weighted scoring.
In contrast, growth mindset patterns are based on a more flexible and open-minded approach to prioritisation. This approach assumes that priorities can change based on new information or feedback, and that the team constantly reevaluates and adjusts priorities as needed. Examples of growth mindset patterns include the 5 lanes pattern and the $500 pattern.
Core prioritisation patterns provide a solid foundation for prioritisation. We encourage teams to use the growth mindset patterns over the fixed mindset patterns to foster a more flexible and adaptable approach to the data work that needs to be done. By being open to new information, feedback and iterative prioritisation, teams can continuously improve and optimise their priorities to ensure that they are delivering the most value to their customers and stakeholders.
Core Prioritisation Patterns
Eisenhower Matrix
The Eisenhower Matrix, also known as the Urgency-Importance Matrix, is a simple two-by-two matrix that helps prioritise work based on their urgency and importance. Work is divided into four categories: Urgent and Important, Important but Not Urgent, Urgent but Not Important, and Not Urgent or Important.
ABC Analysis
ABC Analysis is a prioritisation pattern that categorises work into three groups: A, B, and C. Work in the A category are the most important and urgent, while work in the C category are the least important and can be postponed.
Critical Path Method (CPM)
The Critical Path Method is a pattern that helps prioritise work based on its dependencies. It helps to determine the minimum amount of time required to complete a work by identifying the critical path, which is the sequence of tasks that must be completed on time for the work to be successfully completed.
Fixed Mindset Prioritisation Patterns
There are a number of popular fixed mindset prioritisation patterns.
MoSCow
The Moscow prioritisation pattern is often used to prioritise tasks, features, or requirements in software development. The pattern consists of dividing tasks into four categories based on their level of importance and urgency: Must have, Should have, Could have, and Won't have.
Must have: This is the essential work that must be completed in order for the delivery to be considered a success. This work has a high priority and must be completed before moving on to other work.
Should have: This work is important, but not essential. It should be completed if time and resources permit, but are not critical to the successful delviery of the desired outcome.
Could have: This is work that would be nice to have, but are not essential or particularly important. They may be added if time and resources allow, but should not be given a high priority.
Won't have: This is work that is not necessary and may be postponed or omitted entirely if necessary.
Here's an example of how it could be applied to a data analytics platform:
In this example, the Data Platform Product Owner has identified the essential features for the data analytics platform to function (Must Have), the valuable additions that would improve the product (Should Have), the desirable but not critical features (Could Have), and the ones that can be left out for now (Won't Have).
Kano Model
The Kano model uses customer satisfaction patterns to prioritise customer requirements or product features. The model was developed by Noriaki Kano in the 1980s and is based on the idea that customer satisfaction with a product or service is influenced by a combination of performance, excitement, and basic needs.
The Kano model categories requirements into three groups:
Must-haves: These are basic requirements that customers expect to be fulfilled. Failing to meet these requirements will result in customer dissatisfaction.
Performance requirements: These are requirements that impact customer satisfaction directly proportional to the level of performance provided. The better the performance, the higher the customer satisfaction.
Delighters: These are requirements that exceed customer expectations and provide a source of customer delight. Meeting these requirements can result in increased customer loyalty and positive word of mouth.
Here's an example of how it could be applied to a data analytics platform:
In this example the Data Platform Product Owner has considered the impact of each feature on customer satisfaction, to help prioritise the development of features that are most important to customers.
Value-Effort
The value-effort prioritisation pattern is a method for prioritising work based on the value the work will deliver to stakeholders and the effort required to deliver the work. The goal of this pattern is to identify the work which will provide the most value for the least amount of effort, and prioritise that work first.
To use the value-effort prioritisation pattern, you would create a matrix with two dimensions: value and effort. The value dimension would measure the potential value of the outcome of the work for stakeholders, such as customers, users, or the organisation. The effort dimension would measure the resources required to complete the work, such as time, money, and effort.
Once the matrix is created, you would place each piece of work into one of four categories: high value/low effort, high value/high effort, low value/low effort, and low value/high effort. The work in the high value/low effort category is the work that should be prioritised first, as it provides the most value for the least amount of effort. The work in the low value/high effort category should be avoided or deferred, as it provides little value for a significant amount of effort.
Here's an example of how it could be applied to a data analytics platform:
By considering both the value and effort of each piece of work, the value-effort prioritisation pattern can help the Data Platform Product Owner prioritise the teams efforts on the work that will provide the most value for the least amount of effort, and avoid wasting resources on work that will provide little return.
RICE
The RICE (Reach, Impact, Confidence, and Effort) prioritisation pattern is a method for prioritising work based on four factors: reach, impact, confidence, and effort. The goal of this pattern is to help teams make informed decisions about which work to tackle first, based on the potential impact it will have and the resources required to complete it.
Reach: This refers to the number of people or systems that will be affected by the task. The higher the reach, the more important the task may be.
Impact: This refers to the potential positive or negative impact that the task will have on stakeholders, such as customers, users, or the organisation. The higher the impact, the more important the task may be.
Confidence: This refers to the level of confidence the team has in their ability to complete the task successfully. The higher the confidence, the more likely the task is to be prioritised.
Effort: This refers to the amount of time, money, and manpower required to complete the task. The lower the effort, the more likely the task is to be prioritised.
To use the RICE prioritisation pattern, the team would assign a score to each piece of work for each of the four factors and then combine the scores to create a prioritisation score. The work with the highest prioritisation scores would be prioritised first.
Here's an example of how it could be applied to a data analytics platform:
Implement a new data security measure
Reach: High (affects all customers)
Impact: High (protects sensitive customer data)
Confidence: High (team has experience in implementing similar measures)
Effort: High (significant time and resources required)
Prioritisation Score: (High Reach + High Impact + High Confidence + High Effort) = 12
Improve the data visualisation tools
Reach: Medium (affects some customers)
Impact: High (increases the usefulness of the platform)
Confidence: Medium (team has limited experience with similar improvements)
Effort: Low (relatively straightforward to implement)
Prioritisation Score: (Medium Reach + High Impact + Medium Confidence + Low Effort) = 9
Add a new data export feature
Reach: Low (affects a small number of customers)
Impact: Medium (useful for a specific group of customers)
Confidence: High (team has experience in implementing similar features)
Effort: Medium (modest amount of resources required
Prioritisation Score: (Low Reach + Medium Impact + High Confidence + Medium Effort) = 7
Based on these scores, the Data Platform Product Owner might prioritise the following tasks:
Implement a new data security measure
Improve the data visualisation tools
Add a new data export feature
By considering reach, impact, confidence, and effort, the RICE prioritisation pattern can help the Data Platform Product Owner prioritise which work to tackle first, ensuring that the teams efforts are focussed on work that will have the greatest impact with the available resources.
Weighted Scoring
The Weighted Scoring prioritisation pattern is a method for prioritising work based on multiple factors or criteria. This pattern involves assigning a weight to each factor and then scoring each piece of work based on its performance for each factor. The scores are then multiplied by the weights and summed to determine the overall prioritisation score for each piece of work.
Problems with the fixed mindset prioritisation patterns
There are a number of problems that come with the use of the fixed mindset prioritisation patterns.
The definitions of the prioritisation categories can be ambiguous and open to interpretation, which can lead to confusion and disagreements among stakeholders. Everybody had a slightly different perspective on what is used to define High vs Medium.
Once work has been assigned with its relevant prioritisation categories, and given its comparative prioritisation ranking, it can be difficult to change its priority. It is often a “one and done process” and this results in inflexibility and a lack of adaptability in the face of changing requirements or circumstances.
The prioritisation pattern can lead to an unbalanced workload, with a disproportionate amount of attention and resources being directed towards the high effort and high importance work, while the other categories are neglected and never delivered.
The prioritisation patterns often do not take into account the interdependencies between work, which can result in suboptimal outcomes.
While the use of “scores” to prioritise work gives an impression that prioritisation has been performed on a scientific basis, the logic that assigned those scores is based on opinion and is obfuscated.
The prioritisation process is often arduous and there is little appetite to iterate it once the initial prioritisation has been done.
AgileData prioritisation patterns
There are a number of prioritisation patterns we have found in the agile and product domains which we have proven are useful when used to prioritise work in the data domain.
We use the Information Product Canvas and the Data Platform Press Releases as the inputs for these prioritisation patterns.
5 Lanes
This is one of our favourite patterns to help stakeholders define the priority of the data work to be delivered.
It can be used to prioritise both the Information Product Canvas and the Data Platform Press Releases, although the stakeholders who prioritise each of these may be different..
The 5 lanes pattern is based on the ABC Analysis pattern where we put in place a forcing function to ensure stakeholders cannot place the same prioritisation on multiple pieces of work.
We use this pattern to do an initial prioritisation of the entire Information Product or Data Platform backlog and then use it to iterate the priorities every two months.
Prioritisation Process
The first step is to set up a physical or virtual board with 5 lanes or rows on it. Number the rows from 1 to 5, with 1 at the top and 5 at the bottom.
This can be done using tape on a wall or tape on a large boardroom table (check first that the tape won’t take the paint off the wall or damage the table when you remove it). Or you can use a virtual environment such as Miro or Mural to create an electronic board with the 5 lanes..
The second step is to create cards, one for each Information Product Canvas or Data Platform Press Release that has been defined. These cards can either contain just the Information Product Name, or you may want to include a subset of the information from the canvas, for example the Product Owner name and T-shirt sizing or the Vision statement.
You need to provide enough information for the stakeholder to quickly glean what the Information Product is about. We will often use a card with just the Information Product name and then have copies of the Information Product Canvas readily available if the stakeholder needs more information.
Next you gather a group of stakeholders together to attend the prioritisation workshop and undertake the prioritisation process. These should be the people in the organisation who can make the prioritisation decisions, not people who have been delegated to attend the prioritisation workshop because the key stakeholders are too busy.
Once the stakeholders have gathered for the workshop, explain they are going to work together to prioritise the work that will be done over the next three months and that they will use the Information Product pattern to streamline the process. Explain what an Information Product Canvas is by talking them through one of the canvases.
Outline there are more Information Product Canvas defined than can be delivered within the current three month delivery window. We are focussed on prioritising the work that will be delivered over the next three months, but we will quickly prioritise all the Information Products in this initial workshop.
Another prioritisation workshop will be run in two months time to prioritise the following three months, and to ensure re-prioritisation can happen to reflect any changes in organisational priorities that have happened over that time. This pattern of re-prioritising the Information Product Canvas is rinsed and repeated every two months.
Ask the stakeholders to work together to place the cards for the most important Information Products at the beginning of lane 1 and the least important at the end of lane 5.
Information Product cards can go in any lane and anywhere in that lane. The AgileData team will start with the first Information Product / card on the left hand side of lane 1 and once that is delivered then start on the card immediately to the right.
There are two rules:
Stakeholders cannot put cards on top of each other, if they have the same importance to an Information Product that is already in the lane, then they put the new card to either the left or right of the current card.
All the cards must be placed in a lane
The polices are:
Stakeholders can reorder any placed cards whenever they want, but it must be done in discussion with the other stakeholders.
Stakeholders can shorten the prioritisation process by dumping all the low priority cards in Lane 5
Lanes do not need to be filled, its ok to have a short lane 2 and a full lane 3.
Stakeholders cannot bully other stakeholders.
If there is a HIPPO in the room they should wait until the other Stakeholders have placed all the cards in Lanes and then move the Cards they care about telling the Stakeholders why they are moving that card.
If lane 1 becomes full with cards, then the next card that would have gone into the end of lane 1, gets placed at the beginning of lane 2. All the cards already in that lane get moved right to make space for the new card.
The process is completed when every Information Product card has been placed in a lane.
The entire prioritisation process should take less than two hours to complete. If you have a consistent set of stakeholders for each workshop, then you will find the process will take less time and less time as they become more familiar with the process.
5 Lanes Anti-Patterns
Pre-curate the lanes
You may be tempted to pre-curate the process by putting the cards into the lanes yourself, based on what you understand the priorities are or working with a single individual, such as the Product Owner to do this. Then have the prioritisation stakeholders review and confirm the priorities, or move things around.
Don’t.
The key to this pattern is the conversations about business value and trade-off compromises that happen when stakeholders start with a blank page. If you pre-seed the cards into the lanes, then these conversations tend to not happen, as stakeholders will give it a once over, maybe move one or two cards and then try and finish the session early to get back to their other pressing tasks. The power of the blank space forces the necessary conversations to be had.
500 Dollars
This is the second prioritisation pattern we use often to help stakeholders define the priority of the data work to be delivered in the near term delivery window, typically a 3 month window.
It can be used to prioritise both the Information Product Canvas and the Data Platform Press Releases, although the stakeholders who prioritise each of these may be different.
The $500 pattern is based on the Eisenhower Matrix pattern where we put in place a forcing function to ensure stakeholders identify a small number of things that are the highest priority and should be worked on next.
We use this pattern to prioritise the top three Information Products or Data Platform features to be delivered next and then use it to iterate the priorities once those three things have been delivered.
Prioritisation Process
The first step is to create cards, one for each Information Product Canvas or Data Platform Press Release that has been defined. These cards can either contain just the Information Product Name, or you may want to include a subset of the information from the canvas, for example the Product Owner name and T-shirt sizing or the Vision statement.
You need to provide enough information for the stakeholder to quickly glean what the Information Product is about. We will often use a card with just the Information Product name and then have copies of the Information Product Canvas readily available if the stakeholder needs more information.
The second step is to set up a physical or virtual board with all the Information Products or Data Platform Features cards on it.
Next you gather a group of stakeholders together to attend the prioritisation workshop and undertake the prioritisation process. These should be the people in the organisation who can make the prioritisation decisions, not people who have been delegated to attend the prioritisation workshop because the key stakeholders are too busy.
Once the stakeholders have gathered for the workshop, explain they are going to work together to prioritise the work that will be done over the next three months and that they will use the Information Product pattern to streamline the process. Explain what an Information Product Canvas is by talking them through one of the canvases.
Outline there are more Information Product Canvas defined than can be delivered within the current three month delivery window. We are focussed on only prioritising work that can be delivered over the next three months.
Another prioritisation workshop will be run in two months time to prioritise the following three months. This pattern of re-prioritising the Information Product Canvas or Data Platform Press Releases is rinsed and repeated every two months.
Next we provide the stakeholders with $500 of virtual money. If we are running an in person workshop we use Monopoly money, fake money from a dollar store or print out and cut out fake money. Only use the large denominations, don’t use the $1 or $5. If we are using a virtual board we either create post it notes with virtual currency ($10, $20, $50, $100) so stakeholders can copy and paste them, or we ask the stakeholders to use the text option to type in the amount next to each card.
Ask the stakeholders to place their fake money on the Information Product cards that are the highest value to them, until they have spent all their fake money.
The money can go on any card and they can place as much or as little money on as many cards as they want. The AgileData team will start with the first Information Product / card that has the highest amount of money assigned and once they have completed delivery of that Information Product they will start on the one with the next highest amount of money.
There is one Rule:
Stakeholders are not allowed to touch other Stakeholders' money.
The polices are:
Stakeholders can put as much or as little money as they want on each card, putting $500 on one card is acceptable.
Stakeholders do not need to spend the full $500
Stakeholders can influence other stakeholders to spend money on the cards they think are the highest priority.
Stakeholders cannot bully other stakeholders.
If there is a HIPPO in the room they should place their money down last.
If there is a tie in terms of dollars, for example two cards both are the highest with $450, then the stakeholders can decide to do another round and move some of their money to change the priority. If there is still a tie for the highest priority then the AgileData team decides which one they will work on delivering first.
The process is completed when Stakeholders have either run out of fake money or have decided they will not spend anymore.
The entire prioritisation process should take less than one hour to complete. If you have a consistent set of stakeholders for each workshop, then you will find the process will take less time and less time as they become more familiar with the process.
Levels of Prioritisation
When looking at the AgileData patterns for prioritisation you can see they are all based on prioritising Information Products based on the Information Product Canvas template or Data Platform Features based on the Data Platform Press Release template. It would be fair to say that both these templates are at a high level, so what about prioritising the detailed data work to be done.
An organisational lens
We can adopt the pattern of four levels of prioritisation from the organisational strategy domain.
Strategic prioritisation, which involves prioritising work that is necessary to achieve specific outcomes that are aligned with the long-term vision and mission of the organisation. Strategic prioritisation focuses on allocating resources to work that has the greatest impact on achieving the organisation's strategic outcomes in the long term.
Tactical prioritisation, which involves prioritising work that is necessary to achieve specific outcomes within a defined timeframe. Tactical prioritisation focuses on allocating resources to work that is the most critical to the success of the organisation in the short to medium term.
Operational prioritisation, which involves prioritising daily tasks and activities that are necessary to keep the organisation running smoothly. Operational prioritisation focuses on allocating resources to work that are essential to maintaining business operations, such as customer service, production, and maintenance.
Personal prioritisation which involves prioritising individual tasks and responsibilities based on personal goals, deadlines, and values. Personal prioritisation focuses on allocating time and resources to work that is most important to the individual's success and well-being.
An agile lens
We can also adopt the pattern of four levels of prioritisation from the agile domain..
At the highest level, are patterns such as vision statements, strategies and roadmaps. Roadmaps outline the work that will be necessary to achieve the vision statements. This level is similar to strategic prioritisation, where the focus is on allocating resources to work that will have the greatest impact on achieving the organisation's strategic objectives.
At the next level, are patterns such as user stories, planning and iteration backlogs to prioritise specific work and features that are necessary to deliver what is in the roadmap. This is similar to tactical prioritisation, where the focus is on allocating resources to work that is the most critical to the success of the organisation in the short to medium term.
At the next level, are patterns like Scrum or Kanban to prioritise and manage daily work. This is similar to operational prioritisation, where the focus is on allocating resources to work that are essential to maintaining business operations on a daily basis.
In an agile team, personal prioritisation is also important. Each team member is responsible for managing their own workload and prioritising their tasks based on both team and personal goals, deadlines, and values. This is similar to personal prioritisation, where individuals allocate time and resources to initiatives that are most important to their success and well-being.
Prioritisation Cycle
Roman Pichler has developed a Product Strategy Model which has a pattern we can adopt to show the relationship between the different AgileData artefacts and the differing prioritisation levels.
If we apply this visual cyclic pattern to prioritisation in the AgileData Way of Working we would end up with:
Information Product Canvas and Data Platform Press Release
The Information Product Canvas contains a Vision Statement as part of the canvas. The Data Platform Press Release provides another format for a vision statement.
We use the Information Product Canvas and the Data Platform Press Release patterns to provide inputs into stakeholder prioritisation patterns.
Both of these map to the Strategic level.
The prioritisation of the Information Product Canvas and the Data Platform Press Releases defines the next most important outcomes for the AgileData team to help the organisation work towards achieving its strategy. It provides the “why”.
Roadmaps
The prioritisation patterns we use, for example 5 lanes or $500, create the visual boards we need to articulate the roadmap. We can use the raw output of the prioritisation process to visualise the roadmap, for example the 5 lanes visual, or we can adopt a different visualisation pattern for example the roadmap radar <<<add link>>
We will often maintain separate prioritisation boards / roadmaps for Information Products vs boards or roadmaps for Data Platform Press Releases. We find this separation makes it easier to communicate the priorities compared to a single shared board or roadmap which gets overcrowded and complex.
We will sometimes have a different set of stakeholders who prioritise the Information Products compared to the stakeholders who prioritise the Data Platform Press Releases. We will sometimes use different workshop patterns to prioritise the Information Products vs Data Platform Press Releases. We will sometimes use a different visual board pattern to visualise the Information Product roadmap compared to the visual board pattern to visualise the Data Platform Press Releases. When we do any of these we increase complexity, so we only do these when the benefit of doing so far outweighs the complexity of managing the processes and outputs.
These all map to the Strategic level.
The creation of the roadmaps documents the priority of the work that could be done. It provides the “what next”.
Backlog
<<<describe the flow from Information Product Canvas to User Stories, Backlog and Iteration Planning>>>
These all map to the Tactical level.
The backlog is the bridge between the Vision Statement of “why” and the roadmap of “what next” and provides enough detail so the AgileData team can determine the “how” and “how long”.
Build and Deliver
<<<describe the flow from backlog to single iteration backlog >>>
<<<describe the patterns for daily prioritisation>>>
These all map to the Operational and Personal level.
The AgileData team takes the “why” and the “what next” and then they define the “how” and “how long”.
Measure and Reiterate
<<<describe the patterns for measuring actions we enabled and outcomes were achieved>>>
<<<describe the patterns for iterating the way of working>>>
The Stakeholders and AgileData team determine “did it work” and then work together to determine “what should we iterate in the way we are working next”.
Prioritisation Anti-Patterns
Delegated stakeholders
Stakeholders are busy people and they may try and delegate their attendance at the prioritisation workshop to somebody that reports to them. But while they will delegate the attendance, they often won’t delegate the decision making authority.
This will manifest itself with the delegate stating they will need to “check” with the stakeholder before they can confirm which are the most important Information Products or the stakeholder will ask to be taken through the prioritisation once it has been done to “confirm” it.
For all the AgileData prioritisation patterns we are leveraging self-organising patterns in the prioritisation workshops, which means every attendee needs to be empowered to make or agree the trade-off decisions needed during the workshops. Once we introduce a dependency outside this process we lose the value of the workshop. Once one stakeholder delegates the rest of them are likely to follow and then the workshop becomes a recommendation process not a prioritisation process.
If a stakeholder is not able to attend the workshop or is unwilling to delegate their decision making authority to a person who can attend, then they lose their privilege to be part of the decision making process. In our experience they will only miss it once, when they realise it is the place that decisions on business value are being made.
HIPPO
Depending on your organisation’s culture you may find that the Highest Paid Person’s Opinion (HIPPO) drives the prioritisation process.
You will observe this anti-pattern when the stakeholders in the workshop all defer the prioritisation process to a single individual, and do not actively engage in the prioritisation process themselves.
You will see this happen more often in the 5 Lanes prioritisation workshop pattern, than in the 500 pattern. HIPPO’s seem more comfortable with moving cards around (and people less comfortable with moving them afterwards) and less comfortable telling somebody publically where to place their fake money. So if it is a behaviour you want to modify, change to a prioritisation workshop pattern that restricts this HIPPO behaviour such as 500.
The key outcome of the workshop is a prioritised list of Information Products the AgileData team needs to deliver, and clarity on which one they should deliver first. While we know patterns which involve multiple people crowd-sourcing decisions provide a better outcome, if the organisation culture is for one senior person to make business value and trade-off decisions, then we may want to respect that culture. In that case there is little value in running a workshop with multiple stakeholders attending and we should just run the workshop with the HIPPO on their own.
More than one priority #1
On rare occasions we have worked with stakeholders that end up prioritising multiple Information Products as the top importance, regardless of the prioritisation workshop pattern we use. They will struggle or refuse to select a single Information Product as the highest priority.
In this situation we mention to the stakeholders that given there are multiple priority one Information Products, and therefore they are all of equivalent priority and business value then the AgileData team will choose the order in which they deliver them.
We explain that regardless of the order the team delivers them, all priority one Information Products will be delivered in the same timeframe regardless of which one the team works on first, second and third etc.
Self Organising Team Prioritisation
In an AgileData Way of Working the AgileData team are responsible and accountable to prioritise the work of tasks that are to be done. They are focused on the operational and personal levels of prioritisation.
AgileData teams are responsible for prioritising tasks to be done because they are the one`s who have the best understanding of what it would take to deliver the information needed to achieve the actions and outcomes stated in the Information Product Canvas.
Patterns from the agile domain are based on the principles of collaboration, flexibility, and continuous improvement. These principles require that the team be empowered to make decisions about how to prioritise work, rather than relying on a top-down approach from management.
AgileData teams may work based on a pattern of short iterations, typically lasting one to four weeks, or they may use a flow based pattern to manage their work. The team prioritises the work to be done based on the prioritisation pattern that best matches the way they flow their work. The team collaborates to identify the most critical tasks and features that need to be completed to achieve the stated actions and outcomes. By prioritising tasks in this way, the team can focus on delivering the highest value to the stakeholders and consumers in the shortest amount of time.
Allowing the agile team to prioritise tasks also promotes ownership and accountability within the team. When team members are involved in the prioritisation process, they are more invested in the success of the delivery and more likely to take ownership of their tasks. This can lead to a greater sense of motivation and satisfaction, which can improve the overall quality of the work.
Wake up in the morning exercise
The wake up in the morning pattern is a team workshop exercise that involves prioritising tasks that need to be done upon waking up in the morning.
The goal of this exercise is to illustrate that people can prioritise when they are forced to.
The exercise can be run as an in-person event using post it notes or on a virtual board using virtual notes.
The exercise runs through a number of iterations:
Iteration 1 - Individual Morning Activities
Ask each person to write down the activities they did from the moment they woke up until they reached the office (or started work in their dome office) on post-it notes and put them on a wall in the order they undertook those activities, with the first activity on the left and the last activity on the right.
Each activity should be on a separate sticky note, and everyone should do this individually. Each person should have a different colour post-it note or some other way of visually differentiating their post-it notes.
People can put each post-it note up on the wall as they write them, or write them all at once and then put them on the wall.
You will typically get activities similar to:
Getting out of bed and starting the day
Drinking water and hydrating
Exercising or stretching
Showering and getting dressed
Planning out the day's tasks and priorities
Eating breakfast
Checking emails and messages
Helping children or pets
Commuting or getting to work
We will end up with a row of post-it notes on the wall, for each person.
Iteration 2 - Team Flow Based Grouping
Ask the team to group the activities sequentially from left to right in a way that makes sense as a story with a beginning, middle, and end. For example, wake-up, washing, breakfast, home arrangements, kids, travel, reaching the office.
The team should put similar post-it notes in the same column, for example “clean teeth”. If there are activities only some people do, for example feed the dog, then they still go in their own column, there will just be less post-it notes in that column.
We end up with a messy single row of post it notes, with lots of columns.
Iteration 3 - Forced prioritisation
Draw a line above or below the current row of Post-Its, or select another blank wall for this iteration.
We tell the team they have a very important meeting in the morning that they cannot miss it or be late. Unfortunately, they have woken up late and have only 15 minutes to get out of the house (or to the online meeting in their home office)!
What do they do? Which part of the morning routine will they drop to fit in the minimal time they have?
Ask the team to move the activities they see as critical to above the line (or the new wall) and leave the non critical ones below the line.
Each person is only moving their own post-it notes.
The goal is to get to the meeting safely and be on-time with the minimum activities possible.
We end up with a row of post-it notes above the line and a row of post-it notes below the line.
Iteration 4 - Discuss learnings and patterns
This exercise demonstrates a number of important concepts.
Realising that working within a time constraint will always result in prioritisation of activities and result in work not done.
That every person is different, works in different ways and has different views of what is important.
That visualising flows of work helps us understand and agree the way we work, or identify and Ah free any differences. It also helps with prioritising the activities that will and won't be done.
Working as a group is more fun than working on your own.
The negative impact on a team of multi tasking
<<<TBD>>>
The impact of lack of organisational strategy
<<<TBD>>>