Tools for running
Guidewire delivery.

PMO · BAs · delivery leads · anyone asking “where is my epic?”

The sprint and epic tracker for GWMAIN Track 1. Every maintenance epic, from BA elaboration through dev and QA to the release it shipped in, on one page you can filter, rank and export.

Replaces the spreadsheet that used to be rebuilt by hand every sprint. Because it reads the curated Master WIP set rather than raw Jira counts, it is the number the team can actually stand behind when someone asks what velocity is or what is holding up a release.

• Master WIP
• Velocity & Intake
• Blockers, read from Jira comments
• Production Defects
• BA Sprint Planner
• Release Schedule, synced to Confluence
• Backlog Flow
• Roadmap Planner
• Drag-to-rank
• Export to Excel

Steering group · product owners · workstream leads

The nine MBR initiatives, each with the Jira tickets actually in its scope, what the work is in plain business language, who is blocked, and a burn-down of what is left. Tickets arrive by their Jira label, so nobody maintains a list by hand.

Answers the question a steering meeting really asks — is this initiative moving, and what is in the way — without anyone reading a Jira title like “GD INT: Revise verbiage”. It also proposes requirements nobody has written down yet, so gaps surface before a release rather than after.

• MBR-01 to MBR-09
• Label-driven ticket mapping
• Plain-language ticket notes
• Suggested requirement gaps
• Blockers and owners
• Daily burn-down

Anyone who needs to know who covers what

Who sits on which track, in which role, across maintenance, production defects, integrations and the other Guidewire workstreams.

The roster is what Sprintkeep checks a BA name against. When somebody new starts doing BA work and nobody adds them here, their work shows up as “off-roster” in the velocity tables — so this page is the fix for a reporting gap, not just a contact list.

• Track 1 · 2 · 3
• BA, dev, QA and PO coverage
• Feeds Sprintkeep's BA roster

Runs on its own. Listed so you know where the data comes from.

A Cloudflare Worker that pulls GWMAIN out of Jira every hour, mirrors the release schedule from Confluence, and writes it all to Supabase. Every tool above reads that database rather than talking to Jira directly.

It is also where the reading happens: it summarises each epic's comment trail into a one-line status and works out who a piece of work is actually waiting on. That is the part Jira cannot tell you — the status field says “Ready for Dev” while the comments say approval landed three weeks ago and nobody has assigned a developer.

• Epics, defects and labels
• Comment-derived blockers
• Confluence release dates
• Plain-language fix summaries
• Daily snapshots for trends
• Effort estimates