Defend Your Backlog with RICE Scoring

Build a RICE-scored backlog, write user stories, and defend priorities to stakeholders.

Introduction

30 Second Summary

Everyone has opinions about what to build next. Without numbers to back your priorities, the loudest voice in the room wins.

In this project, you will take your DoorDash product analysis and transform it into a complete Product Owner backlog package. You'll score initiatives with the RICE prioritization framework, write engineering-ready user stories, and practice defending your priorities to a skeptical stakeholder.

What You'll Build

A portfolio-ready Notion workspace containing a RICE-scored backlog, user stories with acceptance criteria, and a stakeholder communication brief.

By the end of this project, you'll have:

A RICE scoring database in Notion that auto-calculates priority scores and reveals where your intuition diverges from data.
Six user stories with Given-When-Then acceptance criteria that prove you can hand work to engineering.
A stakeholder brief that communicates "why this, why now" in under 500 words of plain business language.
Secret Mission: Simulate a stakeholder challenge meeting with Claude where you defend your RICE-backed priorities under realistic pressure.

Are there any prerequisites?

This project builds directly on your completed DoorDash product analysis (problem framing, P0/P1/P2 prioritization, and success metrics). You also need a free Notion account and access to Claude.

Build Your PO Workspace in Notion

Every product decision you make needs a home. Right now, your DoorDash analysis lives as raw thinking. To make it portfolio-ready, you need structured artifacts that a hiring manager can scan in under two minutes.

In this step, you will build the Notion workspace that houses everything: a RICE scoring database, user story templates, and a stakeholder brief. Think of it as the operating system for your product ownership work.

In this step, get ready to:

Create your top-level PO Backlog page with three sub-pages.
Build a RICE scoring database with auto-calculating formula scores.
Sort the database so highest-priority items always float to the top.

Create your workspace page and sub-pages

Your workspace needs a clear hierarchy. One parent page holds three sub-pages, each dedicated to a different deliverable you will produce across this project.

Open Notion in your browser and sign in to your account.
In the sidebar, click New page (or press the + icon at the top of the sidebar).
Title the page DoorDash PO Backlog - your name. For example: DoorDash PO Backlog - Alex Chen.
Press Enter to move your cursor into the page body.
Type /page and select Page from the menu. Name it RICE Scoring.
Repeat the same step to create a second sub-page called User Stories.
Create a third sub-page called Stakeholder Brief.

You should now see your top-level page with three sub-pages nested inside it in the sidebar.

Don't see three sub-pages?

Click the toggle arrow next to your top-level page name in the sidebar to expand it. All three sub-pages should appear as nested items underneath.

If a page ended up at the top level instead of nested, drag it onto your DoorDash PO Backlog page in the sidebar to nest it.

help me fix my Notion page structure

Build the RICE scoring database

The RICE framework scores initiatives by Reach, Impact, Confidence, and Effort. You will build a database that calculates a single priority score from these four inputs, removing gut-feel from your prioritization.

Click into your RICE Scoring sub-page to open it.
Type /database and select Table view (the inline database option). This creates a table directly inside the page.

What is a Notion database?

A Notion database is a structured collection where each row is its own page. Properties (columns) attach metadata like numbers, dates, and tags to each row. The Table view displays it like a spreadsheet.

Your new table has a default Name column already. Now add the remaining properties.

Click the + button to the right of the last column header to add a new property.
Name it Reach and set the type to Number.
Add another property called Impact with type Number.
Add another property called Confidence with type Number.
Add another property called Effort with type Number.
Add a property called RICE Score and set the type to Formula. You will configure the formula in the next substep.
Add a property called Priority Source with type Select. Add three options: P0, P1, and P2.
Add a final property called Problem Link with type Text. This is where you will record which numbered problem from your original brief each initiative addresses.

Why a Select property for Priority Source?

The Priority Source property records your original gut-feel P0/P1/P2 labels from the DoorDash brief. Later, you will compare these labels against the calculated RICE Score to see where intuition and data diverge.

Don't see the property type options?

After clicking + and naming your property, click the Type dropdown below the property name. You will see the full list of types including Number, Formula, Select, and Text.

help me add properties to my Notion database

Add the RICE formula and sort by score

Notion formulas use a prop("PropertyName") syntax to reference other columns. You will wire up the RICE calculation so every row auto-generates its priority score.

Click on the RICE Score column header.
Select Edit property, then click Edit formula.
In the formula editor, enter the following formula:

prop("Reach") * prop("Impact") * prop("Confidence") / prop("Effort")

What does this formula do?

This implements the RICE prioritization formula: Score = (Reach x Impact x Confidence) / Effort. Each prop() call pulls the number value from that column in the current row. Notion auto-calculates the result whenever you fill in the four input values.

Property names inside prop() are case-sensitive. They must match your column names exactly, including capitalization.

Click Done (or click outside the formula editor) to save the formula.

Use the sidebar to insert property names

The formula editor shows a panel on the left listing all your database properties. Click a property name there to insert it into your formula with the correct prop() syntax automatically. This avoids typos.

Now sort the database so the highest-scoring initiatives always appear at the top.

Click Sort in the settings menu at the top of the database.
Click + Add a sort.
Choose RICE Score as the property.
Set the order to Descending.

Your database is now configured. Any rows you add in the next step will auto-sort with the highest RICE scores at the top.

Seeing 0 or empty in the RICE Score column?

That is expected. The formula divides by the Effort property, which is currently empty. Once you add real numbers in the next step, the scores will calculate automatically.

If you see an error instead of a number, check that every property name inside prop() matches your column headers exactly (including capital letters).

help me debug my Notion RICE formula

Your workspace is ready. Next up, you will fill this database with real initiatives from your DoorDash brief and score them with the RICE framework.

Score Your Backlog with RICE

Your PO workspace is set up with a RICE scoring database that auto-calculates priority scores. Now it's time to fill it with real data from your DoorDash brief.

In this step, you'll score each initiative using the RICE framework. This replaces gut-feel P0/P1/P2 labels with defensible numbers that hold up in stakeholder conversations.

In this step, get ready to:

Score each initiative from your DoorDash brief with RICE values.
Compare RICE rankings against your original P0/P1/P2 labels and note divergences.
Write confidence justifications for your top 3 items.

Add and score your initiatives

Each initiative from your original DoorDash brief becomes a row in your RICE database. You'll estimate four factors for each one, and the formula you set up in Step 1 handles the math.

Switch back to your RICE Scoring sub-page in Notion.
Click inside the first empty row under the Name column and type the name of your first initiative from your DoorDash brief.
Add one row for each initiative in your brief. Each row represents a distinct product initiative you previously labelled P0, P1, or P2.
For each row, fill in the Priority Source select property with the P0, P1, or P2 label you originally assigned to that initiative.
Fill in the Problem Link text property with which numbered problem from your original brief this initiative addresses.

Now score each row using the four RICE factors. Use these scales:

Reach: How many DoorDash customers this affects per quarter. Use a number between 1 and 10000 based on your analysis of the user segments.
Impact: Use the scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal.
Confidence: Use a percentage. 100 = high confidence backed by data, 80 = medium, 50 = low/speculative.
Effort: Person-months required. Estimate as whole numbers, or use 0.5 for quick wins that take less than a month.

Fill in the Reach, Impact, Confidence, and Effort columns for every row in your database using the scales above.

As you fill in values, the RICE Score column auto-calculates for each row. Your database re-sorts automatically so the highest-priority items float to the top.

Why these specific scales?

RICE deliberately uses different units per factor. Reach is an absolute number (people affected), Impact is a relative scale (0.25 to 3), Confidence is a percentage (50-100%), and Effort is person-months.

This prevents "everything is high priority" thinking. When you have to commit to specific numbers in different dimensions, it forces you to think critically about each factor separately.

RICE Score column showing 0 or blank?

If any of the four input values (Reach, Impact, Confidence, Effort) is left blank, the formula returns 0 or shows empty. Make sure every cell has a number before checking your score.

Also confirm your Effort column is never set to 0. Dividing by zero produces an error.

Need help troubleshooting your formula?

Help me fix my RICE Score formula in Notion

Compare RICE rankings to your original labels

Your RICE scores now produce a data-driven ranking. The interesting part is where this ranking disagrees with your original P0/P1/P2 gut labels. Those divergences reveal where your intuition was off.

Look at your sorted database. Compare the RICE-ranked order against the Priority Source column. Note where a P1 item has a higher RICE score than a P0 item, or where a P0 item sank lower than expected.
Click the + button at the right edge of your database header row to add a new property.
Name the new property Notes and set its type to Text.
For any row where the RICE ranking disagrees with your original P0/P1/P2 label, write a one-sentence explanation in the Notes column explaining why the numbers diverged from your gut.

What does a divergence note look like?

A good divergence note names what changed your mind. For example: "Originally P0 because it felt urgent, but Reach is only 500 users/quarter. The P1 item affects 5000+ users, which RICE correctly surfaces."

This is the muscle of noticing when your intuition is off. In real prioritization meetings, POs who can articulate why they changed their ranking earn more trust than those who silently shift positions.

Write confidence justifications for your top 3

The Confidence score is the factor most often challenged in stakeholder meetings. A VP will ask: "How do you know this?" Your justification is the ready-made answer.

Identify your top 3 rows by RICE Score (the database is already sorted, so these are your first three rows).
For each of these three items, write a Confidence Justification in the Notes column. Start with the confidence percentage, then state the evidence that supports it and what prevents it from being higher.

What does a confidence justification look like?

Follow this pattern: state the percentage, name the evidence, then name the gap. For example: "Confidence 80%: Based on 3-5 star review data showing 40% of complaints mention this issue. Not 100% because we lack quantitative churn correlation data."

This is the language POs use in real prioritization meetings. It signals that you know what you know, you know what you don't know, and you've decided to act anyway.

If a top 3 item already has a divergence note, add the confidence justification after it in the same Notes field.
Verify that all three justifications name specific evidence from your DoorDash analysis, not generic statements like "seems important."

Reference your original brief

Your DoorDash analysis from the previous project contains user segments, problem statements, and success metrics. Pull specific data points from it. The more specific your evidence ("40% of 1-star reviews mention this"), the more defensible your Confidence score becomes.

Your backlog now speaks in numbers, not opinions. Next up, you'll take your highest-scored initiative and break it into engineering-ready user stories that a developer can pick up and build.

Write User Stories with Acceptance Criteria

Your RICE scores now give you a defensible ranking of what to build first. The next question a hiring manager will ask is: can you translate that priority into something an engineering team can actually pick up and deliver?

In this step, you will break your top-ranked initiative into user stories with structured acceptance criteria. This is where your QA background becomes a superpower. Writing testable pass/fail conditions is something you already know how to do.

In this step, get ready to:

Create a user stories database with structured properties in Notion.
Write 6 user stories for your top RICE-scored initiative.
Add Given-When-Then acceptance criteria and pass the 3C quality check.

Create the user stories database

Each user story needs structured metadata so you can sort, filter, and track readiness. You will build a database that captures who benefits, what they want, why it matters, and whether the story is ready for engineering.

Switch back to your Notion workspace and open the User Stories sub-page.
Type /database and select Table to create a new Table-view database on the page.
The first property (Name) is created automatically. Rename it to Story. This is your title property.

Now add the remaining properties. For each one, click the + next to the right-most property, name it, and choose the correct type.

Add a Select property called As a... with three options: DoorDash Customer, DoorDash Driver, and DoorDash Support Agent.
Add a Text property called I want to....
Add a Text property called So that....
Add a Select property called Priority with three options: Must Have, Should Have, and Could Have.
Add a Text property called Parent Initiative. This links each story back to the RICE item it belongs to.
Add a Checkbox property called Definition of Ready Met. Leave it unchecked for now.

What is the user story format?

The standard format is: "As a [type of user], I want [goal] so that [reason]." Each property in your database maps to one part of that sentence.

This format forces you to name the user, the action, and the business value in every story. It prevents vague requirements like "improve the refund flow" from slipping through.

Now populate the database with 6 user stories for your top RICE-scored initiative.

Add 6 rows to the database. Each row is one user story.
For each row, fill in the As a..., I want to..., and So that... properties.
Set the Priority for each story to Must Have, Should Have, or Could Have.
Set the Parent Initiative to the name of your top RICE-scored item from the previous step.
Think about the different user touchpoints in the flow. A single initiative usually affects customers, drivers, and support agents in different ways.

Cover multiple user types

Do not write all 6 stories for the same persona. Spread them across at least two of the three user types (DoorDash Customer, DoorDash Driver, DoorDash Support Agent). This shows you understand how one initiative creates ripple effects across an organization.

Write acceptance criteria in Given-When-Then format

Acceptance criteria define what "done" looks like for each story. The Given-When-Then format maps directly to the Arrange-Act-Assert pattern you already know from QA testing.

Click on the first row in your database to open it as a full page.
Below the properties, write 3-5 acceptance criteria using the Given-When-Then format.

Structure each criterion as:

Given [precondition or context].
When [a single trigger action].
Then [observable outcome the user sees].

What makes good Given-When-Then criteria?

The When clause contains only a single trigger action. If you find yourself writing "and" in the When clause, you have two criteria combined into one.

The Then clause describes observable outcomes (what the user sees on screen), not internal system behavior (database changes). Product Owners write for stakeholders, not for developers.

Here is an example of a well-structured acceptance criterion:

"Given a customer has received a damaged order, When they select 'Report Issue' within 48 hours of delivery, Then they see resolution options within 3 seconds without needing to contact support."

For each story, think about three angles:

The happy path: what happens when everything works as expected.
The error state: what happens when something goes wrong (network failure, invalid input, timeout).
The edge case: what happens at the boundaries (expired eligibility window, maximum item count, zero-value refund).

Repeat this process for all 6 user stories. Open each row as a full page and write 3-5 criteria per story.

Stuck writing criteria?

If you are struggling to come up with 3 criteria for a story, the story might be too narrow. Consider whether it should be merged with another story. Alternatively, if you have more than 5 criteria easily, the story is too broad and should be split into two.

help me write Given-When-Then acceptance criteria for my user story

Run the 3C quality check and mark stories as ready

Before marking a story as ready for engineering, it must pass a quality gate. The 3C check ensures your stories are actionable, not just written.

Review each of your 6 stories against these three questions:

Clear: Can any stakeholder (not just a developer) understand this story without jargon?
Concise: Is the story one sentence, with 3-5 crisp criteria?
Checkable: Could a tester write a pass/fail test from this criterion alone?

Revise any story or criterion that fails one of these checks. Rewrite jargon into plain language. Split overly broad criteria into separate lines.
Once a story passes all three checks, open it and check the Definition of Ready Met checkbox.
Repeat until all 6 stories have Definition of Ready Met checked.

Why does "Checkable" matter so much?

A criterion that cannot be verified as pass or fail will cause scope creep during a sprint. Engineering will interpret it one way, QA will interpret it another, and the feature ships with mismatched expectations. Binary pass/fail criteria eliminate that ambiguity before work begins.

Return to the Table view of your User Stories database. You should see all 6 rows with the Definition of Ready Met column showing checked boxes across the board.

Your backlog now has teeth. Every priority is backed by RICE data, and your top initiative is broken into stories that an engineering team could pick up tomorrow. Next up, you will write the stakeholder brief that explains "why this, why now" to a skeptical VP.

Write the Stakeholder Brief

Your backlog now has defensible RICE scores and engineering-ready user stories. The missing piece is the communication layer that connects your analysis to a decision-maker.

In this step, you will write a one-page brief that explains your top priorities to a skeptical VP of Engineering. This is the skill that separates POs who get buy-in from those who get overruled.

In this step, get ready to:

Structure your Stakeholder Brief with five clear sections.
Write the brief in plain business language under 500 words.
Add an Anticipated Pushback section with prepared responses.

Structure the brief with five sections

A strong stakeholder brief leads with the recommendation, not a slow build-up to a conclusion. Each section has a specific job that moves the reader toward a yes.

Switch back to your Stakeholder Brief sub-page in Notion.
Type a heading called Context. Below it, write 2-3 sentences explaining what the business problem is and who it affects.
Add a heading called Recommendation. List your top 3 RICE-ranked priorities as a numbered list, each with one sentence explaining why you chose it.
Add a heading called Evidence. Reference the specific RICE scores that support your ranking. Name each initiative and its calculated score.
Add a heading called Trade-offs Acknowledged. Name the items you are NOT doing and explain the opportunity cost of doing them first instead.
Add a heading called Ask. State what you need from engineering: team size, sprint commitment, and timeline.

Why lead with the recommendation?

Senior stakeholders are busy. They want to know what you propose before they hear the reasoning. Leading with context and building to a conclusion buries the point.

The Context section gives just enough framing (2-3 sentences) for the Recommendation to land. Everything after the Recommendation exists to defend it.

Write in plain business language under 500 words

A VP does not want to hear about velocity or story points. They want to hear impact, cost, and timing in language any executive can follow.

Review your brief and remove any Agile jargon. Replace terms like "sprint velocity" or "backlog grooming" with plain equivalents like "delivery pace" or "priority review."
Frame each recommendation in terms of business outcomes. For example: "This will reduce customer churn by X% based on Y evidence, it requires Z engineers for W weeks."
Check your word count. Select all text on the page, copy it, and paste it into any word counter tool. The entire brief must be under 500 words.
If you are over 500 words, cut the weakest sentence from each section. Constraint forces clarity.

The 500-word constraint is intentional

In real stakeholder meetings, you rarely get more than 5 minutes to present. A brief that is tight enough to read in 2 minutes earns trust because it signals you respect the reader's time.

What does plain business language look like?

Instead of: "We need to increase velocity by 20% to ship this epic in Q3."

Write: "We need 3 engineers for 6 weeks to ship this by end of Q3. That is faster than the alternative, which would take 4 months with the same team."

Add the Anticipated Pushback section

Pre-built responses to expected challenges show you have thought beyond your own perspective. This is what separates a polished brief from a first draft.

At the bottom of your brief, add a heading called Anticipated Pushback.
Write 3 questions you expect the VP to ask. Think about what a skeptical engineering leader would challenge: cost, complexity, evidence gaps, or alternative approaches.
Below each question, write a prepared one-sentence response that addresses the concern directly.

What kind of pushback should you anticipate?

Think about three angles a VP might challenge from:

Priority ordering: "Why not the cheaper/faster option first?"
Evidence strength: "How confident are we this will actually move the metric?"
Resource allocation: "Can we do multiple things in parallel instead?"

Review your completed brief one final time. Confirm it has all five main sections (Context, Recommendation, Evidence, Trade-offs Acknowledged, Ask) plus the Anticipated Pushback section at the bottom.
Confirm the total word count is under 500 words.

Brief feels too long or unfocused?

If your Context section is more than 3 sentences, you are over-explaining the problem. The VP already knows DoorDash has issues. Get to the recommendation faster.

If your Trade-offs section is longer than your Recommendation section, flip the ratio. You are spending more words on what you are not doing than on what you are doing.

help me tighten my stakeholder brief to under 500 words

Your brief is ready to present. Next up, you will put it to the test by defending your priorities in a simulated stakeholder challenge meeting.

Secret mission

Defend Your Priorities Under Pressure

You have built the brief. You have prepared the pushback responses. But can you actually hold your ground when a skeptical VP of Engineering challenges your priorities in real time? Use Claude to simulate a stakeholder challenge meeting and find out.

Clean Up Your Resources

This project runs entirely on Notion's free plan and Claude's free tier, so there are no ongoing costs. Decide whether to keep your workspace as a portfolio piece, or remove the pages you created.

Resources you used:

Notion pages (DoorDash PO Backlog and all sub-pages: RICE Scoring, User Stories, Stakeholder Brief, Stakeholder Challenge - Transcript).
Claude conversation history (VP of Engineering stakeholder simulation).

Keep everything running

No action needed. Choose this if you plan to use your Notion workspace as a portfolio artifact in job applications.

Your Notion pages stay accessible at no cost on the free plan.
Your Claude conversation history remains in your account for future reference.
You can share the Notion workspace link directly in job applications or interviews.

Pause - I'll come back to this later

Since everything lives in Notion and Claude's web apps, there is nothing to shut down or pause. Your work persists automatically.

Bookmark your DoorDash PO Backlog page in Notion so you can find it easily when you return.
No processes are running and no resources are consuming credits.

Delete - I don't want to use this again

Remove all project pages from Notion and delete your Claude conversation history.

In Notion, open the DoorDash PO Backlog page.
Click the three-dot menu icon in the top-right corner of the page.
Click Move to Trash. This deletes the parent page and all sub-pages (RICE Scoring, User Stories, Stakeholder Brief, Stakeholder Challenge - Transcript).
To permanently delete, click Trash in the left sidebar, find the page, click the three-dot menu next to it, and select Delete permanently.
In Claude, find the VP of Engineering conversation in your sidebar.
Hover over the conversation title and click the three-dot menu, then select Delete.

Nice Work!

You just built a complete Product Owner backlog package in Notion. From raw prioritization scores to engineering-ready stories to a stakeholder brief you can defend under pressure, this workspace is exactly what hiring managers look for when evaluating PO candidates.

You learned how to:

Build a RICE scoring database in Notion that auto-calculates priority scores and reveals where intuition diverges from data.
Write 6 engineering-ready user stories with Given-When-Then acceptance criteria that demonstrate you can hand work to engineering.
Produce a stakeholder brief that communicates "why this, why now" in under 500 words of plain business language.
Survive a stakeholder challenge simulation and identify communication patterns to strengthen.

Ready to quiz yourself?