This is a complete sprint prioritization tool that takes a messy product backlog and turns it into a defensible roadmap. It is built around the RICE framework (Reach, Impact, Confidence, Effort).
Every product team eventually hits the same wall: more feature requests than engineering capacity, and everyone convinced their thing matters most. RICE is a well-known framework for solving that, but most tools that implement it stop at a static spreadsheet (you fill in numbers, get a score, and move on).
This tool treats RICE as a process, not a one-time calculation. It assumes the qualitative context behind a number matters as much as the number itself. A feature with 60% user demand but 50% engineering confidence shouldn't score the same as one with 60% demand and 95% confidence. This tool is built to make that distinction visible at every step, not just in a final spreadsheet cell.
It also assumes that a roadmap is a sequence, and not just a single decision. Sprint 1 stabilizes, Sprint 2 recovers deferred growth work, Sprint 3 takes strategic bets. The tool is structured around that sequencing logic, not just a single backlog-to-sprint conversion.
- Backlog Builder: capture every feature idea with effort estimates before any scoring happens
- Sprint Builder: score Reach, Impact, and Confidence live with sliders; RICE scores recalculate instantly; a capacity bar tracks sprint points against your fixed budget
- Roadmap View: an alternating timeline of saved sprints, each expandable to show item-level detail and PM notes
- Full Document View: a clean, presentation-ready expansion of the entire roadmap
- Matrix Table: a sortable comparison table across every backlog item, exportable as CSV, XLSX, or copied directly into a spreadsheet
- Learn RICE: a guided, plain-English explainer page for anyone unfamiliar with the framework, complete with a real worked example and a downloadable sample workspace
- Persistent local storage: your workspace saves automatically; export/import as JSON to back up or share a workspace
- Light and dark themes, a collapsible sidebar, and a guided onboarding tour for first-time users
Built entirely in vanilla HTML, CSS, and JavaScript. Just open index.html.
- html2canvas: view-to-image capture for exports
- jsPDF: PDF generation
- SheetJS: XLSX export
- Google Fonts: Plus Jakarta Sans (headings) + Outfit (body)
git clone https://github.com/crypticot/rice-matrix.git
cd rice-matrixOpen index.html in any browser. No dependencies to install, no server required for basic use.
Why scales start at 1, not 0. Reach and Impact are scored 1–10, not 0–10. If something has zero reach, it shouldn't be on the backlog in the first place, and a zero score would always force the RICE result to zero regardless of anything else, which isn't useful information.
Why Confidence steps in increments of 5%. Confidence is an estimate, not a measurement. False precision (claiming 73% confidence) implies more certainty than anyone actually has. Steps of 5% keep the scale honest.
Why unused sprint capacity isn't treated as a bug. Sprints rarely fill to exactly 100% of capacity on purpose. The buffer is intentional headroom for the unknowns that always show up mid-sprint. The tool surfaces this as "buffer available," not "wasted capacity."
Why the tool doesn't block you from exceeding sprint capacity. Real planning isn't always linear. Sometimes you want to deliberately model an over-budget scenario to show a stakeholder what gets squeezed out, or explore a "what if we had two more points" question before committing to anything. The capacity bar warns clearly when you're over budget, but it never locks you out. The decision to stay within budget is yours to make, not the tool's to enforce.
Chidubem Ojukwu · Portfolio · LinkedIn
This was built as part of a learning project, and exists independently as a tool anyone doing sprint prioritization can use.