| Dim | Name | Owner | What it measures |
|---|---|---|---|
| R | Reach | Platform data | % of total active users affected by this task |
| I | Impact | MED-EL (Lex) | How much does this task contribute to the project's goals? |
| C | Confidence | Coopers PM (Gabriela) | How well-understood is this task? Can Coopers commit to it? |
| E | Effort | Coopers PO (Fabiano) | Development cost |
| — | Dependency | Coopers PO (Fabiano) | Does this task block or is it blocked by another? |
| — | MoSCoW | Joint — sprint planning | Release scope label — override for non-negotiable items |
MED-EL owns value (I): they know their goals and their users. Impact is their strategic judgment made explicit and comparable across tasks.
Coopers owns delivery (C + E): Gabriela knows what's scoped well enough to commit; Fabiano knows what it costs. Neither requires client input.
Reach is not owned by anyone: it's a fact read from the platform. Once active user counts by role are available (from Matomo or the WordPress admin panel), R becomes a lookup, not an estimate.
Reach is the proportion of active users affected by the task, expressed as a decimal (60% = 0.6). Active users = users who have completed at least one meaningful action in the platform within the last 30 days (definition pending — see Q1).
Estimated — replace with real counts from Matomo or WordPress admin panel once available.
| Role | Est. % of active users | Notes |
|---|---|---|
| Recipient | ~55–65% | Largest active community group |
| Candidate | ~20–30% | High churn risk at registration; most fragile segment |
| Mentor | ~5–10% | Small group, high leverage |
| Area Manager | ~2–5% | Admin role; small group |
| MED-EL employee | ~1–2% | Internal only |
| Super Admin | <1% | — |
How much does this task help the project reach its goals? If it ships, how meaningfully does it move the needle on what MED-EL is trying to achieve?
| Score | When to use |
|---|---|
| 3 | Directly advances a strategic goal, removes a significant blocker, or resolves a critical user problem |
| 2 | Meaningful contribution — moves the project forward in a noticeable way |
| 1 | Minor contribution — nice to have, low impact on goals |
Confidence is Gabriela's assessment of whether Coopers can commit to this task as a client-facing deliverable. It is a PM judgment — not just a technical readiness check — because Gabriela is the one who communicates sprint outcomes to MED-EL and backs up that commitment.
Gabriela fills C informed by the Friday alignment meeting with Fabiano, creating a governance check: Fabiano's effort estimate feeds into Gabriela's confidence assessment, preventing bias from going unchallenged.
| Score | Meaning |
|---|---|
| 100% | Fully scoped. Fabiano has reviewed; effort is reliable. Gabriela can commit to MED-EL. |
| 75% | Mostly understood. Minor unknowns remain — can commit with a caveat. |
| 50% | Partially scoped. Some discovery needed before committing. |
| 25% | Exploratory. Scope is unclear — don't commit to a sprint yet. |
| Size | Hours | Effort weight (formula) |
|---|---|---|
| S | ≤4h | 0.5 |
| M | 4–8h | 1 |
| L | 8–20h | 2 |
| XL | >20h | 4 |
| Value | Meaning |
|---|---|
| None | No sequencing constraint |
| Soft | Related to another task but not blocking |
| Hard | Blocks or is blocked by another task — must be sequenced |
Release scope label — override when the RICE score alone doesn't capture non-negotiable urgency.
| Label | Meaning |
|---|---|
| Must | Non-negotiable for this release — compliance, legal, or hard deadline |
| Should | Important; should ship this sprint if capacity allows |
| Could | Desirable; schedule by RICE score |
| Won't | Deferred — out of scope for now |
| Task | R | I | C | E | Score | Read |
|---|---|---|---|---|---|---|
| Password reset delay (all users, blocks access) | 0.9 | 3 | 1.0 | S (0.5) | 5.4 | Do now |
| Group search bug (all users, moderate friction) | 0.85 | 2 | 1.0 | S (0.5) | 3.4 | Quick win |
| Candidate registration recovery email | 0.25 | 3 | 0.75 | M (1) | 0.56 | Strong mid |
| Feed redesign (all users, high impact, large scope) | 0.85 | 3 | 0.75 | XL (4) | 0.48 | Important but heavy |
| Area Manager moderation queue | 0.03 | 2 | 1.0 | M (1) | 0.06 | Low — small audience |
Tasks move through three phases before reaching the dev sprint. RICE scoring happens at the third gate — when dev effort can be estimated accurately.
| Who | Responsibilities |
|---|---|
| Faber-Ludens Gonçalo |
Leads UX direction 2–3 sprints ahead of dev. Maintains Reach reference table. Informal advisor on Impact — flags scores that diverge significantly from UX evidence. Reviews RICE Score distribution after each sprint to catch calibration drift. |
| MED-EL Lex (primary) |
Holds the Impact (I) score — MED-EL's strategic judgment on goal contribution. Fills I before sprint planning. In sprint planning: advocates for tasks, challenges Confidence scores if a task ranks lower than expected. |
| Coopers PM Gabriela |
Manages the task pipeline across all phases. Fill Confidence (C) within 24h of task entering RICE pipeline. Flag tasks where C=25% and explain what's needed to improve scope. Facilitate or co-facilitate sprint planning. |
| Coopers PO Fabiano |
Fill Dev Effort (E) and Dependency within 24h of task entering RICE pipeline. Lead the dependency walkthrough in sprint planning. Report available capacity at sprint start. |
Q1 — What defines an "active user" for Reach? R is expressed as % of active users — but "active" is currently undefined. Does viewing the feed count? Liking a post? Sending a message? The threshold likely differs by role (a Mentor who reads but doesn't post is still engaged; a Candidate who logs in once and never returns is not). Until this is defined, R values are estimates and RICE scores are directional only, not reliable for comparison. This must be resolved before the first scored sprint.
Owner: MED-EL + Gonçalo + Gabriela · Needed by: before first scored sprint
| # | Question | Owner | Needed by |
|---|---|---|---|
| Q2 | Should MED-EL be able to create tasks directly in the shared backlog, or only through Coopers? | Gabriela + MED-EL | Before setup |
| Q3 | Is there a separate list for bugs vs UX improvements? Framework may need to apply to both. | Gabriela | Before setup |
| Q4 | What is the actual active user count per role? (to replace estimated R values) | Karam / Gabriela | Before first scored sprint |
| # | Action | Owner |
|---|---|---|
| 1 | ✓ Coopers internal review — scope confirmed: Community list only (Apr 21) | Done |
| 2 | ✓ ClickUp build spec issued to Gabriela + Fabiano (Apr 23) | Done |
| 3 | Gabriela + Fabiano set up RICE fields and views in ClickUp per build spec | Gabriela + Fabiano |
| 4 | Request active user count by role from Karam or WordPress admin panel (Q4) | Gabriela / Karam |
| 5 | Align with MED-EL on active user definition (Q1) — next sprint planning | Gonçalo + MED-EL |
| 6 | Gonçalo walks Lex through the board once it's live | Gonçalo + Lex |
| 7 | Facilitate first sprint planning session with the new system | Gabriela + Gonçalo |
The current process has no shared method for deciding which tasks go into each development sprint. Three friction points surfaced in the Apr 7–8 meetings:
| Who | Pain point |
|---|---|
| Julia + Lex (MED-EL) | We already invest effort prioritizing our requests — but without knowing Coopers' effort estimates, we can't make informed decisions or understand why tasks are deferred |
| Lincoln (Coopers) | We need something simple that both sides can maintain, ideally Value vs Effort |
| Gonçalo (Faber-Ludens) | Effort alone isn't enough — some tasks block others; only Fabiano's team knows those dependencies |
A good framework must solve all three: shared scoring → transparency → faster sprint agreement.
| Framework | Dimensions | Complexity | Effort transparency? | Dependency support? | ClickUp-ready? |
|---|---|---|---|---|---|
| Value × Effort (2×2) | Value (client), Effort (dev) | Low | Yes | No | Yes — 2 fields |
| RICE ✓ Recommended | Reach, Impact, Confidence, Effort | Medium | Yes | No (+ overlay) | Yes — 4 fields + formula |
| ICE | Impact, Confidence, Ease | Medium | Partial | No | Yes — 3 fields |
| MoSCoW | Priority label (4 levels) | Very low | No | No | Yes — 1 dropdown |
| WSJF (SAFe) | Job size, delay cost, risk reduction | Very high | Yes | Partial | Complex |
| Kano | Satisfaction model (5 categories) | Medium | No | No | Yes — custom field |
RICE separates two signals that other frameworks collapse: Reach (how many users are affected — objective, from platform data) and Impact (how much it helps each affected user — strategic judgment, owned by MED-EL). Keeping them separate gives the score more resolution and better sprint planning conversations.
Two overlays are added: Dependency flag (sequencing constraint) and MoSCoW (release scope label). Both are independent of RICE and of each other.