bicep role assignment resource group

Standard way

All examples that you find in the documentation (like this one ), require you to pass the Role Definition Id.  This Id can be found on this page that lists all built-in Azure roles.

Although this works, it’s a cumbersome experience to look up the Role Definition Id and pass it to the role assignments.

Community alternatives

In the community, people came up already with solutions that simplify this:

• Great approach, but cannot be used from within another Bicep template, because of the PowerShell requirement
• A pure Bicep approach, user-friendly, but quite some work to setup

Generate the Bicep module

I wanted to have a Bicep module to perform role assignments on resource group level, similar like Jos described in his blog post.  It had to support all available Azure roles.  Instead of plumbing it myself, I created a simple PowerShell script that generates the Bicep module, based on a template with place holders.  It also includes custom roles that you might have configured in your Azure environments.

The resulting module can be found here or on my GitHub :

This role assignment module gives you auto-complete with all available roles.  Combined with the VS Code extension, this gives a superb developer experience:

Like often, some automation can make your life just easier!  I hope you’ve enjoyed this one!

UPCOMING TRAININGS

CHECK OUT OUR TRAININGS

Azure Integration Services

Azure migration.

• Azure Governance

Azure Security

Azure foundations, recent posts.

• Looking back at INTEGRATE 2024
• Azure Service Bus vs Event Grid Pull Delivery
• Trying the new Microsoft Applied Skills
• Finally a correct way to configure RBAC for DevOps agents!
• What do the new API Management v2 tiers mean for you?
• Announcement
• API Management
• Architecture
• Azure App Service
• Azure Data Factory
• Azure DevOps
• Azure Event Grid
• Azure Functions
• Azure Kubernetes Service
• Azure Policy
• Azure Resource Graph
• Azure Resource Manager
• Azure Service Bus
• Azure Stream Analytics
• BizTalk Server
• Container Apps
• Geen categorie
• Home Automation
• Microsoft Learn
• Service Bus

MEET THE YOUR AZURE COACH TEAM

Your Azure Coach is specialized in organizing Azure trainings that are infused with real-life experience. All our coaches are active consultants, who are very passionate and who love to share their Azure expertise with you.

Toon Vanhoutte

Azure integration services & serverless.

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

Azure and automation

Create role assignments for different scopes with Bicep

When you create Azure resources with Bicep, you are able to set up role assignments as well. This can be very useful in different scenario’s as it enables you to add an extra layer to your infra as code, which you don’t have to perform manually or through other automation. A role assignment is a resource when you use it in Bicep and can be defined as such, but handling the different scope levels can be a challenge. That is why in this post, I will explain how to create role assignments for different scopes with Bicep.

Before you read on, I recommend you scan through this page in the Microsoft Docs , which gives a great explanation of the different properties of a role assignment. In this post, we will focus on how to handle the scope. To do so, I will walk through all scopes with examples of how a template could be deployed.

Management Group Scope

Let’s start with the biggest scope we have available in Azure resource manager: Management Group. This is how you define the role assignment in Bicep:

To deploy it and set the parameters, you can use different methods. For this post I have used PowerShell. As you can see, you need to define the Id for both the roledefinition and the principalID. To make this a bit easier and more readable, I have made use of Get-AzADUser and Get-AzRoleDefinition

Deployment would go like this:

This deployment would refer to the file rbac-mg.bicep , which it will use to give the user [email protected] the reader role over the management group exampleGroup. Of course you change the values to your own use case.

Subscription scope

So how do we do the same for a subscription? Fortunately, we don’t have to make that many changes. We change the following values:

• Change targetScope = 'managementGroup' to targetScope = 'subscription'
• managementGroup()   is changed to subscription()
• managementGroup().id is changed to subscription().subscriptionId

This is all we have to do for the Bicep template. You can find the new template here .

Note: if you don’t define the targetscope, it will by default use the subscription if you use New-AzDeployment. But for readability, you could consider specifying it anyway.

As for the PowerShell deployment, that would now look like this:

The role assignment will be deployed to the current scope of the PowerShell session, which you can find by using Get-AzContext .

Resource Group Scope

The resource scope is very similar to the subscription scope. Again, you change the targetscope and the references from subscription() to  resourcegroup() .  And for resource groups as well you are able to leave out the targetscope, but you could consider adding it for readability.

To see what the Bicep file would look like, click here .

And deployment would go like this:

Resource scope

A resource resource role assignment is a little different than the previous deployments. You need to refer to the resource within the role assignment, which you do with the scope parameter. To show how it works, I have used a storage account as an example.

A role assignment to a resource has a different use case than to one of the other scopes. If you are doing an assignment for users, a Resource scope is possible, but can make your environment very complicated. It is recommended to keep the assignments at a higher level. That is different for managed identities or service principles. They need the least amount of principal and could be set on a resource level. An example is a key vault, where you want the role assignment to be very specific.

This is what the bicep file could look like:

I have removed all flexibility in the storage account to keep the focus. In production, you would want some flexibility in the properties of the storage account.

Deployment is the same method as the resource group scope:

Deployment in Modules

This is all cool, but one of the great things about Bicep is the use of modules! So how would you do that? For Management groups, subscriptions, or resource groups, that is pretty straight forward. All of the above files can be used as a module and deployed from a different file with the following syntax:

Now with Resources, it is a little more difficult. As we have seen before, you have to define the scope within the role assignment. You are not able to use a parameter for this scope, as it needs the resource itself as a scope. This makes it more difficult to provide flexibility. Even if you would consider making use of the existing option, you wouldn’t get flexibility as you need to define the resource type there. So how doe we make sure we don’t have to create a separate rbac-module for every resource type?

The answer can be found in the files in the brand new public registry : you make the role assignment a part of the resource module. So in this case, for every storage account you provide the option to add a role assignment in the module file.

But you still need flexibility. Flexibility to not create a role assignment or to create multiple. Again, we can find a great method at the public registry : we use a for loop that is empty by default. If the role assignment is not needed, just don’t add it as a parameter. If you need more than one, you add them as an array. Let’s see how that would look.

The template

Although the registry uses a submodule, I prefer to add it straight to the resource. This is how the module for a storage account would look:

If we want to create the resource without role assignment, we just omit the roleAssignments parameter. If we do want to create one (or multiple), our main.bicep file would refer to it like this:

By using this method for every resource you have in a module, you will have some duplicate code, but you won’t have a separate rbac-module for every resource type. This will keep your module files clean but still provide flexibility.

So this is how you create role assignments for different scopes with Bicep. You can find all the complete Bicep files that are referred to here .

If you want to learn more about Bicep, follow along with the LearnLive series that are running right now: https://aka.ms/learnlive-iac-and-bicep

Related Posts:

I’m also having a problem with the scope of a role assignment. Your post was helpful, but I do have one question. For the example for management group scope, there’s a parameter called “ManagementGroupId”, but it doesn’t seem to be used. I see the role definition is created a the management group level. Is the role assignment also defined at the management group level by default? I assume that’s the case since the targetScope = “managementGroup”. Thanks.

Great article Barbara. Thanks so much!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

How to modularize a scoped role assignment with Bicep? #5805

{{editor}}'s edit

Whitwaldo jan 30, 2022.

Beta Was this translation helpful? Give feedback.

Agree this would be ideal.

I don't think this is something that will come to be available in the near future.

• We are still waiting for some "work in progress" around passing Resources in as parameters and out as outputs, however there is no current plan for any generic resource types.

These are the proposals for work to be done to encapsulate this capability and this is not currently in scope here. #2246 #2245

Also this PR is in progress. #4971

I would recommend to jump in and contribute on those issues/threads to ensure to communicate that this capability is in demand and why, since that is the body of work that would enable this capability. Like I say "Generic Resource Types" as par…

Replies: 3 comments · 8 replies

Brwilkinson jan 30, 2022 maintainer.

WhitWaldo Jan 30, 2022 Author

matsest Jan 31, 2022

• Numbered list
• Unordered list
• Attach files

Select a reply

Permissioning Azure Pipelines with Bicep and Azure RBAC Role Assignments

How can we deploy resources to Azure, and then run an integration test through them in the context of an Azure Pipeline? This post will show how to do this by permissioning our Azure Pipeline to access these resources using Azure RBAC role assignments. It will also demonstrate a dotnet test that runs in the context of the pipeline and makes use of those role assignments.

We're following this approach as an alternative to exporting connection strings , as these can be viewed in the Azure Portal; which may be an security issue if you have many people who are able to access the portal and view deployment outputs.

We're going to demonstrate this approach using Event Hubs. It's worth calling out that this is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments. So wherever in this post you read "Event Hubs", imagine substituting other Azure resources you're working with.

The post will do the following:

• Add Event Hubs to our Azure subscription
• Permission our service connection / service principal
• Deploy to Azure with Bicep
• Write an integration test
• Write a pipeline to bring it all together

Add Event Hubs to your subscription ​

First of all, we may need to add Event Hubs to our Azure subscription.

Without this in place, we may encounter errors of the type:

##[error]MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.EventHub'. See https://aka.ms/rps-not-found for how to register subscriptions.

We do this by going to "Resource Providers" in the Azure Portal and registering the resources you need. Lots are registered by default, but not all.

Permission our service connection / service principal ​

In order that we can run pipelines related to Azure, we mostly need to have an Azure Resource Manager service connection set up in Azure DevOps. Once that exists, we also need to give it a role assignment to allow it to create role assignments of its own when pipelines are running.

##[error]The template deployment failed with error: 'Authorization failed for template resource {GUID-THE-FIRST} of type Microsoft.Authorization/roleAssignments . The client {GUID-THE-SECOND} with object id {GUID-THE-SECOND} does not have permission to perform action Microsoft.Authorization/roleAssignments/write at scope /subscriptions/\*\*\*/resourceGroups/johnnyreilly/providers/Microsoft.EventHub/namespaces/evhns-demo/providers/Microsoft.Authorization/roleAssignments/{GUID-THE-FIRST} .'.

Essentially, we want to be able to run pipelines that say "hey Azure, we want to give permissions to our service connection". We are doing this with the self same service connection, so (chicken and egg) we first need to give it permission to give those commands in future. This is a little confusing; but let's role with it. (Pun most definitely intended. 😉)

To grant that permission / add that role assignment, we go to the service connection in Azure Devops:

We can see there's two links here; first we'll click on "Manage Service Principal", which will take us to the service principal in the Azure Portal:

Take note of the display name of the service principal; we'll need that as we click on the "Manage service connection roles" link, which will take us to the resource groups IAM page in the Azure Portal:

Here we can click on "Add role assignment", select "Owner":

Then when selecting members we should be able to look up the service principal to assign it:

We now have a service connection which we should be able to use for granting permissions / role assignments, which is what we need.

Event Hub and Role Assignment with Bicep ​

Next we want a Bicep file that will, when run, provision an Event Hub and a role assignment which will allow our Azure Pipeline (via its service connection) to interact with it.

Do note that our bicep template takes the service principal id as a parameter. We're going to supply this later from our Azure Pipeline.

We're now going to write a dotnet integration test which will make use of the infrastructure deployed by our Bicep template. Let's create a new test project:

We'll create a test file called EventHubTest.cs with these contents:

Let's talk through what happens in the test above:

• We read in Event Hub connection configuration for the test from environment variables. (These will be supplied by an Azure Pipeline that we will create shortly.)
• We post a message to the Event Hub.
• We read a message back from the Event Hub.
• We confirm that the message we read back matches the one we posted.

Now that we have our test, we want to be able to execute it. For that we need an Azure Pipeline!

Azure Pipeline ​

We're going to add an azure-pipelines.yml file which Azure DevOps can use to power a pipeline:

When the pipeline is run, it does the following:

• Gets the service principal id from the service connection.
• Compiles our Bicep into an ARM template
• Deploys the compiled ARM template to Azure
• Installs the dotnet SDK
• Uses the Azure CLI task which allows us to access service principal details in the pipeline to run our dotnet test.

We'll create a pipeline in Azure DevOps pointing to this file, and we'll also create the variables that it depends upon:

• azureResourceGroup - the name of your resource group in Azure where the app will be deployed
• location - where your app is deployed, eg northeurope
• serviceConnection - the name of your AzureRM service connection in Azure DevOps
• subscriptionId - your Azure subscription id from the Azure Portal
• tenantId - the Azure tenant id from the Azure Portal

Running the pipeline ​

Now we're ready to run our pipeline:

Here we can see that the pipeline runs and the test passes. That means we've successfully provisioned the Event Hub and permissioned our pipeline to be able to access it using Azure RBAC role assignments. We then wrote a test which used the pipeline credentials to interact with the Event Hub. To see the repo that demostrates this, look here .

Just to reiterate: we've demonstrated this approach using Event Hubs. This is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments.

Thanks to Jamie McCrindle for helping out with permissioning the service connection / service principal. His post on rotating AZURE_CREDENTIALS in GitHub with Terraform provides useful background for those who would like to do similar permissioning using Terraform.

• Add Event Hubs to your subscription
• Event Hub and Role Assignment with Bicep
• Azure Pipeline
• Running the pipeline

bicep role assignment management group

• Certifications
• Our Instructors

The Ultimate Guide to Product Prioritization + 8 Frameworks

Lisa Dziuba

Updated: August 21, 2024 - 26 min read

One of the most challenging aspects of Product Management is prioritization. If you’ve transitioned to Product from another discipline, you might already think you know how to do it. You choose which task to work on first, which deadline needs to be met above all others, and which order to answer your emails in.

Priorities, right? Wrong!

In product management, prioritization is on a whole other level! The engineers are telling you that Feature A will be really cool and will take you to the next level. But a key stakeholder is gently suggesting that Feature B should be included in V1. Finally, your data analyst is convinced that Feature B is completely unnecessary and that users are crying out for Feature C.

Who decides how to prioritize the features? You do.

Prioritization is an essential part of the product management process and product development. It can feel daunting, but for a successful launch , it has to be done.

Luckily, a whole community of Product experts has come before you. They’ve built great things, including some excellent prioritization frameworks!

Quick summary

Here’s what we’ll cover in this article: 

The benefits and challenges of prioritization

The best prioritization frameworks and when to use them 

How real Product Leaders implement prioritization at Microsoft, Amazon, and HSBC

Common prioritization mistakes

Frequently Asked Questions

Benefits and challenges of prioritization

Before we dive into the different prioritization models, let’s talk about why prioritization is so important and what holds PMs back.

Benefits of effective feature prioritization

Enhanced focus on key objectives: Prioritization allows you to concentrate on tasks that align closely with your product's core goals. For example, when Spotify prioritized personalized playlists, it significantly boosted user engagement, aligning perfectly with its goal of providing a unique user experience.

Resource optimization: You can allocate your team’s time and your company’s resources more efficiently. Focusing on fewer, more impactful projects can lead to greater innovation and success.

Improved decision-making: When you prioritize, you're essentially making strategic decisions about where to focus efforts. This clarity in decision-making can lead to more successful outcomes, avoiding the pitfalls of cognitive biases like recency bias and the sunk cost fallacy .

Strategic focus: Prioritization aligns tasks with the company's broader strategic goals, ensuring that day-to-day activities contribute to long-term objectives.

Consider the example of Apple Inc. under the leadership of Steve Jobs. One of Jobs' first actions when he returned to Apple in 1997 was to slash the number of projects and products the company was working on.

Apple refocused its efforts on just a handful of key projects. This ruthless prioritization allowed Apple to focus on quality rather than quantity, leading to the development of groundbreaking products like the iPod, iPhone, and iPad. 

Stress reduction : From customer interactions to executive presentations, the responsibilities of a PM are vast and varied, often leading to a risk of burnout if not managed adeptly. For more on this, check out this talk by Glenn Wilson, Google Group PM, on Play the Long Game When Everything Is on Fire .

Challenges of prioritization

Managing stakeholder expectations: Different stakeholders may have varying priorities. For instance, your engineering team might prioritize feature development , while marketing may push for more customer-centric enhancements. Striking a balance can be challenging.

Adapting to changing market conditions: The market is dynamic, and priorities can shift unexpectedly. When the pandemic hit, Zoom had to quickly reprioritize to cater to a massive surge in users, emphasizing scalability and security over other planned enhancements.

Dealing with limited information: Even in the PM & PMM world, having a strong data-driven team is more often a dream rather than a current reality. Even when there is data, you can’t know everything. Amazon’s decision to enter the cloud computing market with AWS was initially seen as a risky move, but they prioritized the gamble and it paid off spectacularly.

Limited resources : Smaller businesses and startups don’t have the luxury of calmly building lots of small features, hoping that some of them will improve the product. The less funding a company has, the fewer mistakes (iterations) it can afford to make when building an MVP or figuring out Product-Market Fit.

Bias: If you read The Mom Test book, you probably know that people will lie about their experience with your product to make you feel comfortable. This means that product prioritization can be influenced by biased opinions, having “nice-to-have” features at the top of the list.

Lack of alignment: Different teams can have varying opinions as to what is “important”. When these differences aren’t addressed, product prioritization can become a fight between what brings Product-Led Growth, more leads, higher Net Promoter Score, better User Experience, higher retention, or lower churn. Lack of alignment is not the last issue startups face when prioritizing features.

Prioritization Frameworks

There are a lot of prioritization models for PMs to employ. While it’s great to have so many tools at your disposal, it can also be a bit overwhelming. You might even ask yourself which prioritization framework you should…prioritize. 

In reality, each model is like a different tool in your toolbox. Just like a hammer is better than a wrench at hammering nails, each model is right depending on the type of prioritization task at hand. The first step is to familiarize yourself with the most trusty frameworks out there. So, without further ado, let’s get started.

The MoSCoW method

Known as the MoSCoW Prioritization Technique or MoSCoW Analysis , MoSCoW is a method used to easily categorize what’s important and what’s not. The name is an acronym of four prioritization categories: Must have, Should have, Could have, and Won’t have .

It’s a particularly useful tool for communicating to stakeholders what you’re working on and why.

According to MoSCoW, all the features go into one of four categories:

Must Have These are the features that will make or break the product. Without them, the user will not be able to get value from the product or won’t be able to use it. These are the “painkillers” that form the why behind your product, and often are closely tied to how the product will generate revenue.

Should Have These are important features but are not needed to make the product functional. Think of them as your “second priorities”. They could be enhanced options that address typical use cases. 

Could Have Often seen as nice to have items, not critical but would be welcomed. These are “vitamins”, not painkillers. They might be integrations and extensions that enhance users’ workflow.

Won’t Have Similar to the “money pit” in the impact–effort matrix framework, these are features that are not worth the time or effort they would require to develop.

Pros of using this framework: MoSCoW is ideal when looking for a simplified approach that can involve the less technical members of the company and one that can easily categorize the most important features.

Cons of using this framework: It is difficult to set the right number of must-have features and, as a result, your Product Backlog may end up with too many features that tax the development team.

RICE scoring

Developed by the Intercom team, the RICE scoring system compares Reach, Impact, Confidence , and Effort.

Reach centers the focus on the customers by thinking about how many people will be impacted by a feature or release. You can measure this using the number of people who will benefit from a feature in a certain period of time. For example, “How many customers will use this feature per month?”

Now that you’ve thought about how many people you’ll reach, it’s time to think about how they’ll be affected. Think about the goal you’re trying to reach. It could be to delight customers (measured in positive reviews and referrals) or reduce churn.

Intercom recommends a multiple-choice scale:

3 = massive impact

2 = high impact

1 = medium impact

0.5 = low impact

0.25 = minimal impact

A confidence percentage expresses how secure team members feel about their assessments of reach and impact. The effect this has is that it de-prioritizes features that are too risky.

Generally, anything above 80% is considered a high confidence score, and anything below 50% is unqualified.

Considering effort helps balance cost and benefit. In an ideal world, everything would be high-impact/low-effort, although this is rarely the case. You’ll need information from everyone involved (designers, engineers, etc.) to calculate effort. 

Think about the amount of work one team member can do in a month, which will naturally be different across teams. Estimate how much work it’ll take each team member working on the project. The more time allotted to a project, the higher the reach, impact, and confidence will need to be to make it worth the effort.

Calculating a RICE score

Now you should have four numbers representing each of the 4 categories. To calculate your score, multiply Reach, Impact, and Confidence. Then divide by Effort.

Pros of using this framework:  

Its spreadsheet format and database approach are awesome for data-focused teams. This method also filters out guesswork and the “loudest voice” factor because of the confidence metric. For teams that have a high volume of hypotheses to test, having a spreadsheet format is quick and scalable.

Cons of using this framework: 

The RICE format might be hard to digest if your startup team consists mainly of visual thinkers. When you move fast, it’s essential to use a format that everyone will find comfortable. When there are 30+ possible features for complex products, this becomes a long spreadsheet to digest.

Impact–Effort Matrix 

The Impact-Effort Matrix is similar to the RICE method but better suited to visual thinkers. This 2-D matrix plots the “value” (impact) of a feature for the user vs the complexity of development, otherwise known as the “effort”. 

When using the impact–effort matrix, the Product Owner first adds all features or product hypotheses. Then the team that executes on these product hypotheses votes on where to place the features on the impact and effort dimensions. Each feature ends up in one of 4 quadrants:

Quick wins Low effort and high impact are features or ideas that will bring growth. 

Big bets High effort but high impact. These have the potential to make a big difference but must be well-planned. If your hypothesis fails here, you waste a lot of development time. 

Fill-ins Low value but also low effort. Fill-ins don’t take much time but they still should only be worked on if other more important tasks are complete. These are good tasks to focus on while waiting on blockers to higher priority features to be worked out. 

Money pit Low value and high effort features are detrimental to morale and the bottom line. They should be avoided at all costs.

Pros of using this framework:  It allows quick prioritization and works well when the number of features is small. It can be shared across the whole startup team, as it’s easy to understand at first glance.

Cons of using this framework:  If two product hypotheses are “quick wins”, which should go first? For this reason, it’s not the best framework when there are a lot of features. Also, beware of “fill-ins”, as they can take much more time and resources than expected and create loss of focus.

Professor Noriaki Kano, a Japanese educator and influential figure in quality management, developed the Kano model in the 1980s. Since then, it has been widely used by organizations seeking to prioritize customer satisfaction.

Delighters: The features that customers will perceive as going above and beyond their expectations. These are the things that will differentiate you from your competition.

Performance features: Customers respond well to high investments in performance features.

Basic features: The minimum expected by customers to solve their problems. Without these, the product is of little use to them.

The main idea behind the Kano model is that if you focus on the features that come under these three brackets, the higher your level of customer satisfaction will be.

To find out how customers value certain features, use questionnaires asking how their experience of your product would change with or without them.

As time goes along, you may find that features that used to be delighters move down closer towards ‘Basic Features’ as technology catches up and customers have come to expect them, so it’s important to reassess periodically.

Pros of using this framework: Because the model differentiates between basic needs and features that can delight customers, it prioritizes more customer-focused products and services.

Cons of using this framework: The categorization of features into Kano’s categories can be subjective, leading to inconsistencies. It doesn't directly address other crucial aspects like cost, time-to-market, or feasibility, which can also significantly impact product success.

Feasibility, Desirability, and Viability scorecard

Developed by IDEO in the early 2000s, this scorecard takes three core criteria — feasibility, desirability, and viability. It scores each criterion from 1 - 10 for every feature and takes a total to decide on the priority. 

Feasibility Can we build this feature with the skills and resources available? Is it possible to make this particular product hypothesis fast and without hiring extra people? Do you have an available tech stack/tools/cloud storage to do it?

Desirability Does this solve the pain for the customers? Do they want this feature enough to consider paying for it?

Viability How much will users pay for this feature? What’s the (ROI)? Is there any unit economy behind this feature?

Using this framework, your team creates a spreadsheet with product features and puts a score for each parameter. Another way to use this framework is to evaluate MVP ideas for feasibility, desirability, and viability via a team discussion. 

Ideas that have the most support from the team on those parameters can go right into the design sprint . Use the relevant people to help with the evaluation. For example, developers to look at feasibility or Product Marketing Managers to discuss desirability. This scorecard is pretty straightforward with clear pros and cons:

Pros of using this framework: The flexibility of the FDV scorecard means it can be used for evaluating marketing initiatives, hypotheses for customer success teams, or MVP concepts. It works well for teams that don’t find rigid frameworks helpful or for a workshop, or discussion on the executive level. 

Cons of using this framework: This approach relies a lot on knowledge of what the customer wants and how complex new features are. That is not always data that is readily available. 

Weighted Scoring Prioritization

This method follows a similar pattern to other frameworks on this list but with the significant addition of weighting how much of each category counts towards the final total. 

The process starts by selecting the criteria/categories you’ll be using to rate the features. For example, you might select “user experience”, “sales value”, “strategic impact”, “user adoption” or any of the Acquisition, Activation, Retention, Referral, Revenue (AARRR) metrics.

Next, you need to decide what importance you give to each category, adding a percentage value to each criterion (up to 100%). For example, during the early stages, you might focus on UX features that make an MVP usable. Each feature will have a score in those categories, from 1 (min impact) – 100 (max impact). Then you can now calculate the final score for each feature.

Pros of using this framework: The framework is customizable, which allows you to utilize the framework throughout an organization’s lifetime.

Cons of using this framework: Sometimes the weighting percentages can be hard to decide on. It requires PMMs & PMs to understand how each feature will influence user adoption across the whole product ecosystem. 

Cost of Delay

The Cost of Delay framework is unique in that it focuses exclusively on monetary value. The framework is designed to calculate the cost of not producing the feature immediately. It’s relatively straightforward to understand, although the calculation itself does require careful consideration. 

The calculation is as follows:

Estimated revenue per unit of time , for example, how much could be billed over a month-long period if the feature existed.

Estimated time it will take to complete the development of the feature.

Divide the estimated revenue by the estimated time to give you the cost of delay.

Pros of using this framework: This is a highly effective way of prioritizing feature backlogs. It is also useful in helping team members align around the value of features in terms of ROI.

Cons of using this framework: For new companies or brand-new features, the revenue estimate is very much based on a gut feeling as there is no hard data to base the estimates on.

Product Tree

Luke Hohmann introduced the concept of ‘Prune the Product Tree’, in his book Innovation Games: Creating Breakthrough Products Through Collaborative Play . During a Product Tree session, stakeholders use stickers, markers, or digital equivalents to place features, ideas, and enhancements on different parts of the tree according to where they think they belong in terms of product development priorities. 

Roots : Represent the core technologies, systems, and cap

abilities that support and enable the product's basic functions. These are fundamental aspects without which the product cannot function.

Trunk : Symbolizes the product's main functionalities or the current set of features. It is the stable and established part of the product that supports further growth.

Branches : Illustrate different areas of the product that can grow and expand, such as new feature sets, product lines, or major enhancements.

Leaves : Stand for specific features, ideas, or small enhancements that can be added to the product. These are often more visible to the end-users and can directly contribute to user satisfaction and product value.

Which model should I use?

Knowing which prioritization framework to use is tough! The Kano model is useful for making customer-centric decisions and focus on delight, but it can take time to carry out all the questionnaires needed for your insights to be accurate and fair.

Many people like the RICE scoring system as it takes confidence into account in a qualitative way, but there are still a lot of uncertainties.

MoSCoW focuses on what matters to both customers and stakeholders, which is particularly useful for Product Managers who struggle with managing stakeholder expectations. However, there’s nothing stopping you from putting too many items in ‘Must have’ and overextending your resources.

Of course, these aren’t the only prioritization techniques out there, and many talented Product Managers have their own ways of doing things. All you can do is test, test, and test again!

How to prioritize individual tasks: Tips from busy product leaders

Microsoft: applying the eisenhower matrix to a busy inbox.

Microsoft Product Manager Anusha Bahtnagar, uses a prioritization technique called The Eisenhower Matrix to prioritize what comes into her inbox. As a Product Manager working with cross-continental teams, it’s common to wake up to a full inbox.

The Eisenhower Matrix effectively sorts your tasks/emails into four categories, and presents a solution.

Important and Urgent: Top priority tasks that require your urgent attention (eg, crisis management tasks.)

Urgent and Not Important: Time-sensitive tasks that could be handled by someone else. Delegate these tasks.

Important and Not Urgent: Tasks that you definitely need to do, but they can wait. Schedule these for the future.

Not Important and Not Urgent: Declutter and eliminate tasks.

Amazon and Google: Making customer-focused prioritization decisions

A common theme across many companies is that the customer comes first. The same goes for prioritization.

Asal Elleuch, a Senior Product Manager for Amazon Prime, calls prioritization “a never-ending and iterative process.”

Focusing on the customer gives you an incredibly useful yardstick for prioritization. After all, your company’s values should already be customer focused. And most of your stakeholders should also be aligned on The Why. 

The Product vision should also be heavily influenced by customer needs.

Being customer-focused in your prioritization will help keep your decisions aligned with everything else. Like one big customer-centric puzzle!

Google product teams achieve this by using North Star Metrics . Your North Star Metric can be any metric or action that provides the most value to the customer. For instance, Spotify’s North Star Metric might be clicking ‘play’ on a song. Google Search’s North Star Metric might be clicking on a search result.

You can then base your prioritization decisions around that metric. Whichever updates/features/bug fixes will have a greater impact on that metric has priority.

HSBC: The art of making impossible product decisions

To help make decisions, with so many outside influences and an interlocking web of things to consider, Product Leader Mariano Capezzani came up with his own prioritization system.

Broken down into 4 steps, it gives you a solid footing for making quality prioritization decisions.

Know the context . Understand things like how this task/feature fits with the KPIs of the company, the market trends, and related upcoming regulations.

Understand the need. Learn to differentiate between what customers are asking for and what they really need.

Consider the execution. Are you aware of the intricate network of dependencies and their interlock that are needed to deliver something?

Arrange the sequence. Apply a quick acid test to ensure it fits your criteria (contributes to company goals, benefits a market, etc.)

Common Product Prioritization Mistakes

Mistake 1: no agreed-upon scoring guide.

What does an impact score of “5” mean? A 1% growth or 10%? In conversion rate or MRR? Do other teammates think the same?

Without an agreed-upon scoring guide, you can’t make an apples-to-apples comparison between initiatives. This makes prioritization pointless. To make matters worse, it increases the likelihood of conflicts between team members, as you are essentially disguising opinions as objective decisions. 

How to fix it

Develop a shared scoring guide for your prioritization criteria. Define what each level entails with a concrete description and examples. Here’s an example guide for determining the confidence level:

A scoring guide can be created for any prioritization method, as long as it is:

Specific to your product and team context

Objective and clear

It’s important to point out that even with a guideline, there will still be disagreements — and that’s okay. Team members should be comfortable explaining their decisions and giving feedback to others. These discussions will help your team uncover blind spots and build alignment.

Mistake 2: Mixing discovery and delivery

Software development isn’t the only thing that takes time when building a product. So do problem analysis and solution design, commonly referred to together as product discovery .

However, discovery tasks usually get either:

Lumped in with development work → Creates messy dependency issues.

Left out of the prioritization process → Introduces a selection bias from the start.

Divide your product development into discovery and delivery, and prioritize the two backlogs separately. This is called Dual Track Development . 

Do note that having separate tracks doesn’t mean you should have separate teams. For any given project, the same team should carry out both discovery and delivery work to maximize quality and velocity. 

Mistake 3: Recency bias

Your team will always add items to the backlog faster than it will clear them. Over time, you will build up a long backlog with items from the previous century (year). Because it’s human nature to favor shiny new ideas (a.k.a. recency bias), old items tend to get forgotten for no good reason. 

As new evidence emerges, situations change, and your team’s estimation skills improve, you must constantly review old items to correctly prioritize the backlog.

Track the “freshness” of each item. When something has not been updated for longer than X period of time, groom it again using the latest information. If it’s no longer relevant, it’s time to remove it permanently.

Mistake 4: Not considering constraints 

Product development is inherently messy. Besides the core value-vs-cost consideration, there are also dependencies, deadlines, skill fit, strategic fit, and other constraints that influence your prioritization decisions.

No matter how ruthless you are with prioritization, you can’t simply dismiss these constraints. However, you also shouldn’t let them override your core prioritization criteria every single time. 

Teams that lack a good system to deal with these external factors often end up losing confidence in their prioritization processes altogether. 

Define a set of rules to work with these constraints, and make them part of your prioritization system.

Here are a few examples:

Time-sensitive projects → Set aside a fixed amount of resources each month to fast-track projects with non-negotiable deadlines (e.g., scheduled launch events, seasonable campaigns). Everything else will follow the regular process, even if it means not getting done at all.

Dependencies → A project blocked by other tasks will resume its position in the backlog as soon as the blocker is removed. However, it shouldn’t interrupt projects that have already started.

Strategic alignment → Assign more weight to projects that align with the company’s strategic priorities. This can be done with the Weighted Scoring method.

When you have consistent guidelines, people will trust the system, knowing that every decision is made objectively. 

Mistake 5: Over-complicating the process

Perfect prioritization does not exist. The information you use for prioritization is simply a set of estimations and estimations are always wrong . There is no need to treat your prioritization process like you’re planning a rocket launch. 

Prioritization is an exercise that helps you maximize your execution value. If you constantly direct more resources toward prioritization than execution, you are doing it wrong. 

Sometimes product teams spend months debating the relative value between small features when they could have shipped them all in the time lost.

Timebox your prioritization discussion. If your team gets stuck comparing initiatives, introduce a tie-breaker rule. For example, items that entered the backlog first go first. 

The point is, trivial differences will not matter in the long run, and if you never decide what goes first you’ll never get started.

Mistake 6: Not iterating the prioritization system 

No one gets prioritization right the first time. Even if you are satisfied with your current system, there will always be room for improvement if you look hard enough. Additionally, just because something works today doesn’t mean it’ll continue to work as the company scales. It’s dangerous to think you can create a prioritization system that requires minimal iterations. 

Treat your prioritization system (and other internal processes) like your product. Monitor how it’s working and iterate continuously. Because the “users” in this case are your team members, there should be an open channel for everyone to give feedback.

Generally speaking, frequent and small iterations are better than drastic revamps. However, be aware that:

It takes time for a new process to show its effects.

A new process can hurt productivity in the short term.

Not every problem has an easy solution.

To avoid interrupting team momentum with ad-hoc fixes, I recommend doing a quarterly or bi-yearly process review to go over all the feedback and discuss solutions as a team.

Bonus: Management interference

Having to rearrange your backlog due to management input, usually without a convincing reason, is one of the most frustrating yet common things that can happen to a product team. This is often due to a disconnect between company strategy and product strategy.

Such a discrepancy exists for a combination of reasons:

Management mistakes tactics for strategies. It dictates solutions instead of creating a direction for potential solutions.

Management doesn’t explain the “why” behind a strategy.

There is no clear process for teams to share learnings and evidence (both horizontally and vertically).

There is no agility in the company strategy, even when it no longer makes sense.

If you are a product leader (CPO, director, team lead, etc.), you have a critical responsibility here to bridge the gap between individual teams and senior management. Make sure to communicate information bi-directionally and fix misalignment proactively. A good way to start is by examining:

How are we sharing insights other teams should know?

Does every team have the same access to key information (ICP, positioning, data dashboard, etc.)?

What information does my team want to know but is out of their reach?

What is the best framework for prioritizing product features?

There is no ‘best framework’. There is only the best framework for a given prioritization task. Now that you’re familiar with the frameworks that product experts use day-to-day, look back at your OKRs and decide which model will turn your backlog into the right product at this moment in time. 

Who prioritizes the backlog?

The Product Manager is typically responsible for finalizing the prioritization, balancing stakeholder interests, user value, and feasibility.

Developers provide input on feasibility and effort estimates to help the PM. Stakeholders help PMs and developers understand business value and promote strategic alignment.

What is the best prioritization tool? 

There are tons of great prioritization tools out there, like our free template pack , which includes templates for 5 prioritization models. 

Whatever tool you use, the most important thing is to align around the model you’ll use and make sure everyone is using the same model in pursuit of the same OKRs, and make sure to clarify priorities within the timeline of your product roadmap so everyone is aligned.

What are the steps involved in using a prioritization framework?

Follow these general steps whenever using a prioritization model: 

Identify the moment: Identify the tasks in the backlog, strategy, and current OKRs.

Decide on a framework that will help you reach your team’s goals and apply it to the tasks in the backlog.

Try other frameworks and see if the same features came in first place.

How often should you review your prioritization framework?

Your team should review its priorities regularly. The cadence of that review depends on your team’s needs. How often is not important as long as it’s consistent. Always re-evaluate your prioritization framework if business objectives change. 

Can you use multiple prioritization frameworks?

Yes! In fact, some frameworks pair together as well as a nice chablis and fresh oysters:

Pair subjective and quantitative frameworks for contrast. For example: Cost of Delay + Kano model will balance revenue and customer delight.

Pair bird’s eye views with detailed analysis. Some frameworks are based on a general sense of the market and user trends while others on careful research. Cover your bases by using both. For example: Weighted Scoring + MoSCoW.

Prioritization in product management is less about ticking off tasks and more about leading your product in the right direction. It is a crucial part of framing the priorities within your product roadmap. It is a continuous process of assessment, reassessment, and realignment with your product goals and market needs. 

Product Roadmapping Micro-Certification (PRC)™️

Product School has partnered with Productboard to create a micro-certification on how to build and maintain effective Roadmaps. Enroll for free to learn how to communicate the product vision and strategy to your stakeholders and customers.

Updated: August 21, 2024

Subscribe to The Product Blog

Discover Where Product is Heading Next

Share this post

By sharing your email, you agree to our Privacy Policy and Terms of Service

Prioritization Techniques for the Product Owner

• Website for Mary Iqbal
• Contact Mary Iqbal
• Twitter for Mary Iqbal
• LinkedIn for Mary Iqbal
• Facebook for Mary Iqbal

As a Product Owner , one of your most critical responsibilities is deciding how to order Product Backlog items in the Product Backlog. With limited resources and ever-evolving customer demands, mastering the art of feature prioritization is essential to creating a successful and user-centric product. In this article, we will explore some complimentary practices which the Product Owner might use to as an input when deciding how to order the Product Backlog. These tools should be seen as optional practices that the Product Owner might use when making their day-to-day decisions about the content and ordering of the Product Backlog.

Understanding the Importance of Prioritization

Ordering Product Backlog items in the Product Backlog isn't simply about arranging them in a list. It's about making informed decisions that align with your product's vision, your business goals, and most importantly, your customers' needs. By carefully choosing which features to deliver first, the Product Owner can maximize the value that your product delivers while minimizing the risk of investing resources in features that may not resonate with your audience. The complimentary practices below can help bring clarity to your thought process and can be used to potentially involve stakeholders in the process as well.

The MoSCoW Method: Must-Have, Should-Have, Could-Have, Won't-Have

I had the opportunity to collaborate with a team on the re-platforming of a major consumer website. When we embarked on this initiative, we faced uncertainty about where to initiate our efforts. Determining the most crucial features and establishing a starting point from a technical perspective presented challenges. To gain insights from our stakeholders, we opted to employ the MoSCoW prioritization technique.

We began by compiling an exhaustive backlog of all potential features for the final product. This comprehensive list was then presented to stakeholders for feedback. Stakeholders were asked to categorize each feature according to the MoSCoW framework: "Must Have," "Should Have," "Could Have," and "Won't Have." Through productive stakeholder discussions, we gained a deeper understanding of their perspectives on feature importance.

The outcomes of the MOSCOW session proved invaluable to the Product Owner's process of ordering the Product Backlog.

Here's how it works:

This technique provides a systematic approach to categorize features into four distinct categories, denoted as follows. Engage stakeholders either remotely or in person and guide them through each feature within the Product Backlog. For each feature, prompt stakeholders to assign it to one of the following categories:

Must-Have (M): Encompassing essential features crucial for the core functionality and immediate usability of the product. These features are pivotal to fulfilling the primary purpose of the product.

Should-Have (S): Pertaining to features that, while important, aren't critical for the initial release. They enhance the user experience and contribute value, but the product can operate effectively without them.

Could-Have (C): Referring to features that provide added benefits to specific user segments. These are considered as "nice-to-haves" and can be included in subsequent releases if resource availability allows.

Won't-Have (W): Designating features that have been intentionally deprioritized. These features might not align with current objectives or could demand disproportionate resources in relation to their value.

The MoSCoW method, while a valuable tool, remains a strategic hypothesis. It's essential to recognize that the true importance to the customer only becomes clear upon product release.

Additionally, regardless of the outomes of the MoSCoW exercise, the Product Owner always remains the final decision maker on the content and ordering of the Product Backlog. The Product Owner may choose to order their Product Backlog to reduce risk, consider technical or business dependencies or may decide that certain features are more important to the customer than stakeholders believed. Whatever the Product Owner's decision, the organization should respect their decision.

The Kano Model: Customer Satisfaction and Delight

The Kano model provides a little more emphasis on how the organization hypothesizes that customers will feel about the different features which could be build for the Product. Rather than "Must Have", "Should Have", etc., the Kano Model focuses on the relationship between features and customer satisfaction.

Using, the Kano model, the Product Owner and stakeholders should review items from the Product Backlog and classify them into five categories as shown below.

Basic Needs: These are the fundamental features that customers expect. They don't necessarily impress customers, but their absence leads to dissatisfaction.

Performance Needs: These features directly correlate with customer satisfaction. The better their performance, the more satisfied customers are.

Excitement Needs: These unexpected features delight customers and can set your product apart from competitors. They aren't crucial, but they generate excitement and positive sentiment.

Indifferent Needs: These features neither significantly impact satisfaction nor cause dissatisfaction. They're often best minimized to avoid unnecessary complexity.

Reverse Needs: These features, if present, can actually lead to dissatisfaction for some users. Understanding and avoiding them is crucial.

As with all prioritization techniques, the outcome should serve as input into the Product Owner's decision-making process. The Product Owner may need to consider additional aspects such as technical dependencies or risk when they make their decisions about the content and ordering of the Product Backlog.

The RICE Method: Reach, Impact, Confidence, Effort

The RICE method is a data-driven approach that helps you quantify and compare different feature ideas. This method is particularly useful for Marketing teams who need to prioritize their efforts according to what will have the greatest impact for the largest number of people.

Many marketing teams - especially internal teams serving a larger organization - receive far more requests than they can actually fulfill. How does the Product Owner decide between the needs of the various stakeholders requesting time from the Marketing organization? The RICE method can help. RICE takes into account Reach, Impact, Confidence and Effort and can help the Product Owner make more thoughtful decisions about the content and ordering of their Product Backlog.

The Product Owner or their delegate should review requests for inclusion in the Product Backlog through the lens of Reach (how many users are impacted), Impact (how positive of an impact the feature will have), Confidence (how confident estimates are), and Effort (how much effort will it take to deliver each feature)." By considering these four elements, the Product Owner can make more educated decisions about the content and ordering of the Product Backlog.

Reach: Evaluate how many users a feature will impact. This could be a percentage of your user base or a specific customer segment.

Impact: Measure the potential impact of the feature on user satisfaction, engagement, revenue, or any other relevant metric.

Confidence: Assess how confident you are in your estimates for reach and impact. More uncertain features should have lower confidence scores.

Effort: Estimate the resources (time, money, manpower) required to develop the feature.

By calculating the RICE score (Reach × Impact × Confidence / Effort), you can prioritize features that offer the highest value relative to their cost.

Prioritizing features is an ongoing process that requires a deep understanding of your product's purpose and your users' needs. The MoSCoW, Kano, and RICE methods offer distinct yet complementary approaches to feature prioritization. Depending on your product, combining elements from these frameworks can provide a well-rounded strategy for making informed decisions.

Remember that context matters. Your product's stage, market conditions, and user feedback should all influence your prioritization decisions. Regularly revisit and refine your priorities to ensure your product roadmap remains aligned with your vision and responsive to changing dynamics.

By mastering the art of feature prioritization, you can steer your product towards success, delivering value to your users and achieving your business goals in a strategic and impactful way.

To learn more about the Product Owner accountability in Scrum, signup for Rebel Scrum’s Professional Scrum Product Owner course.

Expand your horizons and learn from thought leaders in Scrum and Kanban at this year’s Scrum Day conference in Madison, Wisconsin.  This conference has something for everyone from our groundbreaking keynotes to break-out sessions for Scrum Masters, Executives, Product Owners, Developers and those who are just curious about Scrum.

And while you are in town, don’t miss the Badger game at Camp Randall Stadium on September 16!

What did you think about this post?

Share with your network.

• Share this page via email
• Share this page on Facebook
• Share this page on Twitter
• Share this page on LinkedIn

View the discussion thread.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Management group deployments with Bicep files

• 6 contributors

This article describes how to set scope with Bicep when deploying to a management group.

As your organization matures, you can deploy a Bicep file to create resources at the management group level. For example, you may need to define and assign policies or Azure role-based access control (Azure RBAC) for a management group. With management group level templates, you can declaratively apply policies and assign roles at the management group level.

Training resources

If you would rather learn about deployment scopes through step-by-step guidance, see Deploy resources to subscriptions, management groups, and tenants by using Bicep .

Supported resources

Not all resource types can be deployed to the management group level. This section lists which resource types are supported.

For Azure Blueprints, use:

• blueprintAssignments

For Azure Policy, use:

• policyAssignments
• policyDefinitions
• policySetDefinitions
• remediations

For access control, use:

• privateLinkAssociations
• roleAssignments
• roleAssignmentScheduleRequests
• roleDefinitions
• roleEligibilityScheduleRequests
• roleManagementPolicyAssignments

For nested templates that deploy to subscriptions or resource groups, use:

• deployments

For managing your resources, use:

• diagnosticSettings

Management groups are tenant-level resources. However, you can create management groups in a management group deployment by setting the scope of the new management group to the tenant. See Management group .

To set the scope to management group, use:

Deployment commands

To deploy to a management group, use the management group deployment commands.

For Azure CLI, use az deployment mg create :

For Azure PowerShell, use New-AzManagementGroupDeployment .

For more detailed information about deployment commands and options for deploying ARM templates, see:

• Deploy resources with ARM templates and Azure CLI
• Deploy resources with ARM templates and Azure PowerShell
• Deploy ARM templates from Cloud Shell

Deployment location and name

For management group level deployments, you must provide a location for the deployment. The location of the deployment is separate from the location of the resources you deploy. The deployment location specifies where to store deployment data. Subscription and tenant deployments also require a location. For resource group deployments, the location of the resource group is used to store the deployment data.

You can provide a name for the deployment, or use the default deployment name. The default name is the name of the template file. For example, deploying a template named main.bicep creates a default deployment name of main .

For each deployment name, the location is immutable. You can't create a deployment in one location when there's an existing deployment with the same name in a different location. For example, if you create a management group deployment with the name deployment1 in centralus , you can't later create another deployment with the name deployment1 but a location of westus . If you get the error code InvalidDeploymentLocation , either use a different name or the same location as the previous deployment for that name.

Deployment scopes

When deploying to a management group, you can deploy resources to:

• the target management group from the operation
• another management group in the tenant
• subscriptions in the management group
• resource groups in the management group
• the tenant for the resource group

An extension resource can be scoped to a target that is different than the deployment target.

The user deploying the template must have access to the specified scope.

Scope to management group

To deploy resources to the target management group, add those resources with the resource keyword.

To target another management group, add a module . Use the managementGroup function to set the scope property. Provide the management group name.

Scope to subscription

You can also target subscriptions within a management group. The user deploying the template must have access to the specified scope.

To target a subscription within the management group, add a module. Use the subscription function to set the scope property. Provide the subscription ID.

Scope to resource group

You can also target resource groups within the management group. The user deploying the template must have access to the specified scope.

To target a resource group within the management group, add a module. Use the resourceGroup function to set the scope property. Provide the subscription ID and resource group name.

Scope to tenant

To create resources at the tenant, add a module. Use the tenant function to set its scope property. The user deploying the template must have the required access to deploy at the tenant .

Or, you can set the scope to / for some resource types, like management groups. Creating a new management group is described in the next section.

Management group

To create a management group in a management group deployment, you must set the scope to the tenant.

The following example creates a new management group in the root management group.

The next example creates a new management group in the management group targeted for the deployment. It uses the management group function .

Subscriptions

To use an ARM template to create a new Azure subscription in a management group, see:

• Programmatically create Azure Enterprise Agreement subscriptions
• Programmatically create Azure subscriptions for a Microsoft Customer Agreement
• Programmatically create Azure subscriptions for a Microsoft Partner Agreement

To deploy a template that moves an existing Azure subscription to a new management group, see Move subscriptions in ARM template

Azure Policy

Custom policy definitions that are deployed to the management group are extensions of the management group. To get the ID of a custom policy definition, use the extensionResourceId() function. Built-in policy definitions are tenant level resources. To get the ID of a built-in policy definition, use the tenantResourceId() function.

The following example shows how to define a policy at the management group level, and assign it.

To learn about other scopes, see:

• Resource group deployments
• Subscription deployments
• Tenant deployments

Was this page helpful?

Additional resources

Home » Agile Development » Prioritizing Requirements with MoSCoW Method: A Guide for Agile Projects

Prioritizing Requirements with MoSCoW Method: A Guide for Agile Projects

• Posted on March 28, 2023
• / Under Agile & Scrum , Agile Development , Project Management

The MoSCoW method is a prioritization technique used in project management, software development, and business analysis. It helps to prioritize requirements based on their importance and urgency, and allows project managers to allocate resources and budget accordingly. In this article, we will explore the MoSCoW method and provide an example of its implementation.

What is the MoSCoW Method?

The MoSCoW method is a prioritization technique that categorizes requirements into four groups: Must-haves, Should-haves, Could-haves, and Won’t-haves. The acronym MoSCoW stands for:

• Must have: critical requirements that are essential for the project’s success. These requirements are mandatory and must be included in the project scope.
• Should have: important requirements that are necessary for the project’s success but can be delayed if necessary. These requirements are important, but not critical, and can be deferred to a later phase of the project.
• Could have: desirable requirements that are not essential for the project’s success, but can enhance the project’s value. These requirements are optional and can be included if time and budget allow.
• Won’t have: requirements that are not needed for the project’s success and are not included in the project scope.

The MoSCoW method helps project managers prioritize requirements based on their importance and urgency. It allows them to focus on the critical requirements and allocate resources and budget accordingly.

Example of MoSCoW Method

Let’s consider an example of a software development project to understand how the MoSCoW method works.

Suppose a company wants to develop a new mobile app for its customers. The app should allow customers to order products, track their orders, and receive notifications. The company also wants to include some additional features to make the app more appealing to customers.

The project team identifies the following requirements:

• Must have: The app must allow customers to order products, track their orders, and receive notifications.
• Should have: The app should have a search feature that allows customers to search for products, and a payment feature that allows customers to pay for their orders using various payment methods.
• Could have: The app could have a loyalty program feature that rewards customers for their purchases, and a referral program feature that incentivizes customers to refer the app to their friends and family.
• Won’t have: The app won’t have a social media integration feature that allows customers to share their purchases on social media platforms.

Using the MoSCoW method, the project team has prioritized the requirements based on their importance and urgency. The must-have requirements are critical for the success of the project and must be included in the app. The should-have requirements are important, but can be deferred to a later phase of the project if necessary. The could-have requirements are optional and can be included if time and budget allow. The won’t-have requirements are not needed for the project’s success and are not included in the project scope.

Real-life Example – CRM System

Project Description: Development of a Customer Relationship Management (CRM) System

The objective of this Agile project is to develop a CRM system for a small business that specializes in providing customized solutions to its clients. The CRM system will be designed to streamline the sales process and improve customer interactions, allowing the business to enhance customer satisfaction and loyalty.

The project will follow the Agile methodology, which involves iterative and incremental development. The Agile team will work closely with the client to gather requirements, develop prototypes, and deliver functional software increments in short iterations, typically two weeks.

Identify a List of User Stories

To create the list of user stories, you can considered the different roles that would interact with the system, such as sales representatives, managers, and customers, and thought about the various tasks they would need to perform in order to achieve their goals. you can also considered the different types of data that would need to be stored and managed within the system, such as customer information, sales data, and marketing campaigns.

Based on this analysis, you can then generated a list of user stories that covered a broad range of functionality, from lead tracking and customer service, to sales proposals and reporting. The list of user stories is intended to provide a starting point for the development team to use in prioritizing and planning the development of the CRM system.

Here is a list of user stories for the CRM system development project:

• As a sales representative, I want to be able to track all of my leads in one place so that I can easily manage my sales pipeline.
• As a sales manager, I want to be able to view and monitor my team’s progress in real-time so that I can provide coaching and support as needed.
• As a customer service representative, I want to be able to view all of a customer’s interactions with our company so that I can provide personalized support.
• As a marketing manager, I want to be able to segment our customers based on their preferences and behavior so that I can target them with relevant campaigns.
• As a customer, I want to be able to view my purchase history and account information so that I can easily manage my relationship with the company.
• As a customer service representative, I want to be able to log and track customer complaints and inquiries so that I can ensure that they are addressed in a timely manner.
• As a sales representative, I want to be able to generate quotes and proposals quickly and easily so that I can close deals faster.
• As an administrator, I want to be able to manage user permissions and access levels so that I can control who has access to sensitive information.
• As a sales representative, I want to be able to schedule and manage appointments with my clients so that I can stay organized and on top of my schedule.
• As a manager, I want to be able to generate reports on sales performance, customer satisfaction, and other metrics so that I can make informed business decisions.

These user stories cover a range of functionality that the CRM system should provide. The development team can use these user stories to prioritize the most important features for the system, and to ensure that the system meets the needs of all stakeholders.

In table format, let’s present a clear and concise summary of the 10 user stories related to a business scenario to provide an overview of the user stories.

The table provides information on the user role, the specific goal they want to achieve, and the user story number to easily reference each story. By organizing the user stories in a table, it is easier to understand and prioritize the features that need to be developed to meet the needs of the stakeholders involved in the project. This table can serve as a reference for the development team to design and implement features that align with the needs of the end-users and stakeholders.

Prioritize the User Stories

It is important to prioritize the user stories based on their business value and impact on the project goals. This ensures that the development effort is focused on the most important and valuable features, and that the project can be delivered on time and within budget.

Prioritization can be done using various techniques such as the MoSCoW method, which categorizes user stories as “must-haves,” “should-haves,” “could-haves,” and “won’t-haves.” User stories categorized as “must-haves” are the most critical and should be developed first, while “should-haves” and “could-haves” can be developed later in subsequent iterations or releases.

Here’s a table for the 10 user stories mentioned earlier, with the relevant information and prioritization based on the MoSCoW method:

In this table, the user stories are listed in order of priority, with the “must-have” features listed first, followed by the “should-haves” and “could-haves.” The “won’t-haves” feature is not planned for implementation in this project, but may be considered for future development.

By prioritizing the user stories, the development team can ensure that the most critical features are developed first, providing value to the stakeholders and enabling the project to meet its objectives within the time and budget constraints.

Example: A Scrum Development Plan for the CRM

here is a high-level outline for a Scrum development plan to start the agile project. However, the specific details of the plan will depend on the project requirements, team structure, and other factors. Here’s an example of a Scrum development plan:

• Define the Product Backlog: The first step is to define the product backlog, which is a prioritized list of all the features, functionalities, and requirements that need to be implemented in the project. This backlog will be maintained throughout the project and will be continually refined and updated based on the changing needs of the stakeholders.
• Conduct Sprint Planning: After the product backlog has been defined, the team will conduct a sprint planning meeting to select a set of user stories from the backlog to be developed in the upcoming sprint. The team will estimate the effort required for each user story, and select the user stories that can be completed within the sprint timeframe.
• Conduct Daily Scrum Meetings : Once the sprint has started, the team will conduct daily scrum meetings to review progress, identify any obstacles or challenges, and adjust the plan as needed. The daily scrum meetings should be short and focused, with each team member providing an update on their progress.
• Develop the Product Increment: During the sprint, the team will work on developing the selected user stories, focusing on delivering a working product increment by the end of the sprint. The team will collaborate closely, with developers, testers, and other team members working together to deliver the product increment.
• Conduct Sprint Review: At the end of the sprint, the team will conduct a sprint review meeting to demonstrate the product increment to the stakeholders, gather feedback, and review the progress made during the sprint.
• Conduct Sprint Retrospective: After the sprint review, the team will conduct a sprint retrospective meeting to review the sprint process, identify areas for improvement, and plan for the next sprint.
• Repeat the process: The team will repeat this process for each subsequent sprint, continuing to refine and update the product backlog, and focusing on delivering a working product increment at the end of each sprint.

This Scrum development plan provides a framework for managing the agile project, with regular meetings and reviews to ensure that the project is on track and delivering value to the stakeholders.

The article discusses the MoSCoW method, which is a prioritization technique used in Agile project management to prioritize project requirements. The MoSCoW method divides requirements into four categories: Must-have, Should-have, Could-have, and Won’t-have. The article provides a real-life example of an Agile project and how to identify user stories for the project. The user stories are then prioritized using the MoSCoW method, with the Must-have requirements given top priority.

The article also outlines a Scrum development plan, which includes defining the product backlog, conducting sprint planning, daily scrum meetings, developing the product increment, sprint review, sprint retrospective, and repeating the process. The Scrum development plan provides a framework for managing the Agile project, ensuring that the project is on track, and delivering value to stakeholders.

Leave a Comment Cancel reply

You must be logged in to post a comment.

• Visual Paradigm Online
• Request Help
• Customer Service
• Community Circle
• Demo Videos
• Visual Paradigm
• YouTube Channel
• Academic Partnership

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Add RBAC role on a Azure blob storage container with Bicep

I'm deploying an azure datalake gen 2 storage account with bicep. I want to assign roles (groups) on a containers with bicep (see code below). But I keep getting an error. Can someone help me ?

According to the document you should add a condition but this also doesn't work.

• azure-blob-storage
• azure-resource-manager
• azure-bicep

• 1 can you try with roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '2a2b9908-6ea1-4ae2-8e65-a410df84e7d1') ? –  Thomas Commented Apr 5, 2022 at 19:52

The roleDefinitionId property is the resource identifier of the role. It is also a subscription level resource so you would define it in the bicep file like that:

• I'm hoping this will also be the answer to my latest question - will update soon! –  Rob Bowman Commented Nov 4, 2022 at 18:11

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged azure azure-blob-storage azure-resource-manager azure-bicep or ask your own question .

• The Overflow Blog
• From PHP to JavaScript to Kubernetes: how one backend engineer evolved over time
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...

Hot Network Questions

• Can the subjunctive mood be combined with ‘Be to+infinitive’?
• Sticker on caption phone says that using the captions can be illegal. Why?
• Why are volumes of revolution typically taught in Calculus 2 and not Calculus 3?
• When was this photo taken?
• Can pedestrians and cyclists board shuttle trains in the Channel Tunnel?
• Are Experimental Elixirs Magic Items?
• Are automorphisms of matrix algebras necessarily determinant preservers?
• Melee Opportunist--making opportunity attacks have some bite for melee characters
• Calculate the sum of numbers in a rectangle
• How can I push back on my co-worker's changes that I disagree with?
• Book about a colony ship making an unscheduled stop in a star system with no habitable planets
• Jacobi two square's theorem last step to conclusion
• If Miles doesn’t consider Peter’s actions as hacking, then what does he think Peter is doing to the computer?
• What are the limits of Terms of Service as a legal shield for a company?
• How to determine if a set is countable or uncountable?
• Seth and Cain take turns picking numbers from 1 to 50. Who wins?
• What's the counterpart to "spheroid" for a circle? There's no "circoid"
• Why cant we save the heat rejected in a heat engine?
• If the Collatz conjecture is undecidable, then it is true
• Should I GFCI-protect a bathroom light and fan?
• grep command fails with out-of-memory error
• Which game is "that 651"?
• Degree of a cyclotomic polynomial
• Reshape an image with ImageMagick