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.
| Dim | Name | Owner | What it measures |
|---|---|---|---|
| R | Reach | Platform data | % of total active users affected by this task |
| I | Impact | MED-EL | Per-user effect — how much does this move the needle for each affected user? |
| C | Confidence | Coopers PM (Gabriela) | How well-understood is this task? Can Coopers commit to it? |
| E | Effort | Coopers dev (Fabiano) | Development cost |
| — | Dependency | Coopers dev (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 move the needle for each affected user?
| Score | When to use |
|---|---|
| 3 | Removes a blocker, resolves a significant frustration, or directly advances a strategic KPI |
| 2 | Meaningful improvement — users will notice and benefit |
| 1 | Minor improvement — nice to have, low individual effect |
How well-understood is the task? Can Coopers commit to delivering it as described?
| Score | Meaning |
|---|---|
| 100% | Fully scoped. Fabiano has reviewed; effort is reliable. |
| 75% | Mostly understood. Minor unknowns remain. |
| 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 |
| Field | Type | Owner | Options |
|---|---|---|---|
| Reach (R) | Number (0–1) | Platform data | Decimal from role distribution table |
| Impact (I) | Dropdown | MED-EL | 1 / 2 / 3 |
| Confidence (C) | Dropdown | Coopers PM | 25% / 50% / 75% / 100% |
| Dev Effort (E) | Dropdown | Coopers dev | S / M / L / XL |
| Dependency | Dropdown | Coopers dev | None / Soft / Hard |
| Blocked by | Relationship | Coopers dev | Link to blocking task |
| MoSCoW | Dropdown | Joint | Must / Should / Could / Won't |
| RICE Score | Formula or Number | Auto / Fabiano | (R × I × C) ÷ E weight |
Backlog Board (shared) — Table view, sorted by RICE Score descending. MED-EL fills I; Gabriela fills C; Fabiano fills E and Dependency.
Sprint Planning View — Board view, grouped by Sprint (Backlog / Current / Next / On Hold). Used in the joint biweekly session.
Dependency Map — List view, filtered by Dependency = Soft or Hard. Used by Fabiano + Gonçalo before each sprint for sequencing review.
| Who | Responsibilities |
|---|---|
| MED-EL Julia, Lex, Marina |
Fill Impact (I) on every task before sprint planning. Can create tasks directly in Backlog with I pre-filled. In sprint planning: advocate for tasks; ask about Confidence if a task ranks lower than expected. |
| Coopers PM Gabriela |
Fill Confidence (C) within 24h of task submission. Flag tasks where C=25% and explain what's needed to improve scope. Facilitate or co-facilitate sprint planning. |
| Coopers dev Fabiano |
Fill Dev Effort (E) and Dependency within 24h of task submission. Lead the dependency walkthrough in sprint planning. Report available capacity at sprint start. |
| Faber-Ludens Gonçalo |
Maintains Reach reference table (updated when new user data is available). Informal advisor on Impact — flags scores that diverge significantly from UX evidence. Reviews RICE Score distribution after each sprint to catch calibration drift. |
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 | Does the current Coopers ClickUp plan support formula fields? | Gabriela | Before setup |
| Q3 | What is the current sprint cadence — weekly or biweekly? | Gabriela | Before setup |
| Q4 | Should MED-EL be able to create tasks directly in ClickUp, or only through Coopers? | Gabriela + MED-EL | Before setup |
| Q5 | Is there a separate list for bugs vs UX improvements? Framework may need to apply to both. | Gabriela | Before setup |
| Q6 | 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 of this document — feedback to Gonçalo | Lincoln, Gabriela, Fabiano |
| 2 | Schedule ClickUp setup call (~30 min): confirm plan, create fields, set up views, backfill existing tasks | Gabriela + Fabiano + Gonçalo |
| 3 | Request active user count by role from Karam or WordPress admin panel (Q6) | Gabriela / Karam |
| 4 | Align with MED-EL on active user definition (Q1) — next biweekly | Gonçalo + MED-EL |
| 5 | Facilitate first sprint planning session with the new system | Gabriela + Gonçalo |