Sorry Engineering by Rafal Makara

Share this post

User's avatar
Sorry Engineering by Rafal Makara
Variations of ICE prioritisation
Copy link
Facebook
Email
Notes
More
User's avatar
Discover more from Sorry Engineering by Rafal Makara
Common sense driven Engineering Management
Already have an account? Sign in

Variations of ICE prioritisation

Rafal Makara's avatar
Rafal Makara
Dec 08, 2022

Share this post

User's avatar
Sorry Engineering by Rafal Makara
Variations of ICE prioritisation
Copy link
Facebook
Email
Notes
More
Share

There is only 1 tool in the world that works well for prioritisation. It is a list. Something on top of the list is more important than something at the bottom.

Multiple lists lead to competing priorities.

Multi-dimensional presentation of the priorities moves the accountability away from leadership and typically overloads people with work and context switching.

We can use many techniques to get an artifact of a prioritised list.

One of them is ICE.

ICE Scoring

ICE stands for:

  • I - Impact

  • C - Confidence

  • E - Ease

You score each dimension on a scale from 0 to 10. And then, you calculate the ICE score as:

ICE = Impact * Confidence * Ease

After getting all the scores, you sort by ICE Score and have your prioritised list.

The Impact dimension is about assessing how impactful this thing will be. Ease is about how easy this thing will be to develop, test and launch.

Confidence is a more tricky thing depending on the source. One definition is about how confident you are about guesses impact and ease. Another definition might be the confidence of moving you closer to your north star metric by getting this backlog item done.

I will leave the definitions here. You can read about them from multiple sources on the Internet. Just Google “ICE Prioritisation”.

For sure, ICE helps prioritise product experiments / bets.

In this article, I want to mention 2 useful ICE variations.

Variation A: Bugs and Support

When dealing with bugs or support requests, we do not need Confidence.

Instead of that, we may exchange that with U - Urgency. It is a factor that enables our (e.g.) Customer Success Team to manipulate the prioritisation a little bit.

Maybe one big customer calls them daily - it might be an urgent thing, important for our company.

In that case, we may end up with the following:

  • I - Impact

  • U - Urgency

  • E - Ease

I found that useful for prioritisation of bugs and support requests.

You end up with:

IUE = Impact * Urgency * Ease

Variation B: Split the Impact

In some contexts, describing the Impact dimension can be challenging.

In some teams, I found it helpful to split the Impact dimension into:

  • Severity - Is the critical user journey crashed? Or is it a supportive feature?

  • Scope - Are 5 million customers affected or just 1 customer?

In that case, you want to build a single number from Severity and Scope, so you end up with the following math:

ICE = ((Severity + Scope)/2) * Confidence * Ease

You can read more about this way of prioritising an impact by Googling “RICE Prioritisation”. I didn’t use the terms “Reach” and “Impact” just to show that you can build your definition of the original Impact dimension that works best for you.

Alternative approaches for math

In standard ICE definition, you can find this kind of math:

ICE = Impact * Confidence * Ease

But you may also experiment with:

ICE = (Impact * Confidence) / Ease

Tool for building a shared understanding

The obvious benefit of using this kind of prioritisation technique is building the final list of priorities we can use to decide on what we want to work on first.

However, there is also another one.

Most discussions about something being more or less important are very opinionated, subjective and not driven by the data. Often extroverts win.

By converting our opinions into numbers, we can start discussing why person A believes it creates an impact of 4, while the other person believes it is 8.

It leads to collaborative learning about our product, the business we are building something for, and everything behind feasibility.


Thank you for reading Sorry Engineering. This post is public, so feel free to share it.

Share

Thanks for reading Sorry Engineering! Subscribe for free to receive new posts.

Share this post

User's avatar
Sorry Engineering by Rafal Makara
Variations of ICE prioritisation
Copy link
Facebook
Email
Notes
More
Share

Discussion about this post

User's avatar
I got fired once
I got fired from one of the companies in the past. That became a funny story to tell during job interviews and parties. I think... company owners who…
Nov 7, 2022 • 
Rafal Makara
5

Share this post

User's avatar
Sorry Engineering by Rafal Makara
I got fired once
Copy link
Facebook
Email
Notes
More
Journey to High-Performing Team
When referring to building teams, we often mention Tuckman's stages of group development: forming–storming–norming–performing. That helps understand the…
Nov 3, 2022 • 
Rafal Makara
2

Share this post

User's avatar
Sorry Engineering by Rafal Makara
Journey to High-Performing Team
Copy link
Facebook
Email
Notes
More
Agenda of "hello meetings" when joining a new company/team
When I join a new company or a team, I meet with everyone for a short 1:1 hello meeting. The agenda of each meeting is as follows: Story about Rafal…
Nov 16, 2022 • 
Rafal Makara
2

Share this post

User's avatar
Sorry Engineering by Rafal Makara
Agenda of "hello meetings" when joining a new company/team
Copy link
Facebook
Email
Notes
More

Ready for more?

© 2025 Rafal Makara
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More

Create your profile

User's avatar

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.