Sprint Reality — User Guide

Delivery intelligence for Jira — honest signals, never guesswork.

Sprint Reality reads the data already in your Jira — issues, sprints, versions, dependencies, assignments and history — and turns it into a clear answer to one question: will we deliver? Every feature is built to answer that, and its two follow-ups: why not? and what next?

This guide covers every feature, what it shows, how it is calculated in plain language, and a worked example for each. No prior setup knowledge is assumed.

Table of contents

1. Core concepts (read this first)
2. Where to find everything
3. Your first 10 minutes
4. Permissions and roles
5. Delivery & risk
   • Delivery Dashboard
   • Sprint Health
   • Release Readiness
   • Dependency Radar
   • Delivery Analytics
6. Planning & capacity
   • Capacity Planner
   • Resource Forecasting
   • Predictive Simulation
   • Delivery Cost Intelligence
7. Quality & people
   • Requirements Quality
   • Technical Debt
   • Engineering Credit Score™
   • Team Health
8. Intelligence & reporting
   • Decision Log
   • AI Delivery Advisor
   • AI Project Investigator
   • Smart Digest
9. Organization-wide
   • Portfolio Intelligence
   • Dependency Heatmap
10. Administration
    • Roles & permissions (Enterprise)
    • Audit log
    • Settings you can configure
11. Optional integrations & setup
12. "Why is my number missing?" — the trust rule in practice
13. Roadmap
14. FAQ & troubleshooting
15. Support

1. Core concepts (read this first)

Understanding these five ideas makes every screen in Sprint Reality easy to read.

Every number is real

Sprint Reality never fabricates a value to fill a gap. If a signal cannot be computed — no active sprint, no release planned, a search that hit its limit, an integration that isn't connected — it excludes that factor, lowers its confidence, and tells you why with a small caveat (⚠). A blank or "not connected" is the truth, not an error.

How to read any score

Wherever you see a 0–100 score, it is never a black box. Each score shows:

• The number (0–100) and a health lozenge — Healthy (70+), At risk (40–69), or Critical (below 40).
• A confidence level — High, Medium, or Low. Confidence drops when inputs are missing or data was capped.
• A formula — the plain-text recipe, e.g. 0.5×SprintHealth + 0.5×Release.
• The factors — each contributing sub-score with its weight, so you can see exactly what moved the number.
• Caveats (⚠) — anything excluded or capped, stated openly.

Example. A Sprint Health score of 62 · Medium confidence with a caveat "Meeting load not connected — excluded" means: the score is a genuine 62 from the data available, but it doesn't include meeting overhead, so treat it as a slightly optimistic read.

The three questions

Every feature maps to one of: Will we deliver? (scores and verdicts), Why not? (risks, blockers, root causes), What next? (recommendations, forecasts, simulations).

AI is optional and never acts

Sprint Reality works fully without any AI. Everything is computed deterministically. The optional AI layer only rephrases findings the app already computed into plain language — it never invents numbers and never changes anything in your Jira.

Respect for Jira permissions

You only ever see data for projects you can already access in Jira. Sprint Reality requests read-only Jira access and layers its own roles on top (see Roles & permissions).

2. Where to find everything

Sprint Reality appears in four places in Jira:

On the project page, the cards lay out 2–3 per row on a wide screen and stack to a single column on a narrow one, so the workspace is readable on any display.

3. Your first 10 minutes

1. Open a Jira project → Sprint Reality in the sidebar.
2. Start on the Dashboard — it gives you the single Go / Caution / No-Go verdict and the numbers behind it.
3. If a factor says "excluded" or "no active sprint," that's expected — the app is telling you what it can and can't measure right now.
4. Click into Sprint Health, Dependency Radar, and Release Readiness to see the detail behind the verdict.
5. (Admins) Configure a few things to unlock more: a blended hourly rate (Delivery Cost), a team roster + PTO (Capacity), and digest channels (Smart Digest). See Administration.

You do not need to add custom fields or change your process. Sprint Reality reads the Jira you already have.

4. Permissions and roles

Sprint Reality has three app roles, layered on top of your Jira permissions. You can never gain an app role on a project you can't see in Jira.

By default your role is derived from Jira: Jira project admins → Admin, everyone else who can browse the project → Viewer. An admin can explicitly assign someone the Editor or Admin role, or downgrade a Jira admin to Viewer to restrict them within Sprint Reality. See Roles & permissions.

5. Delivery & risk

5.1 Delivery Dashboard

• Answers: Will we deliver?
• Where: Project page → Dashboard (the default view).

What you see. A headline verdict — GO, CAUTION, or NO-GO — with a one-line rationale, then the key numbers: overall delivery score, active blockers, any SLA breaches, and the recommendation for the next release. Below, three cards break down the overall score, release readiness, and dependencies side by side.

How it's calculated. The overall delivery score composes Sprint Health (50%) and Release Readiness (50%). Dependency risk is tracked alongside and surfaced as its own signal. If there's no active sprint, Sprint Health is excluded and the score is composed from what's available, with lowered confidence.

Example. Team Aurora's Dashboard shows CAUTION — "Release confidence is conditional; 2 blockers past SLA." Overall delivery is 58, active blockers 3 (2 breached), release recommendation CONDITIONAL. The message is clear: you're likely to ship, but the two breached blockers are the thing to fix before it becomes a NO-GO.

Act on it. Treat CAUTION as "fixable if you act now." Click into Dependency Radar for the specific blockers and Release Readiness for the failing gates.

5.2 Sprint Health

• Answers: Will we finish this sprint? Why not?
• Where: Project page → Sprint Health. Also works on a sprint-scoped surface if opened there.

What you see. The sprint name with a health lozenge, then headline metrics: Sprint Health score, success probability (%), predicted carry-over (points likely to spill to next sprint), and scope creep (% of work added after the sprint started). A score breakdown card shows the formula, each factor, and any caveats. Failure warnings appear as coloured messages.

How it's calculated. The score combines progress-versus-time, scope stability (creep), and carry-over risk, calibrated against the sprint-start baseline Sprint Reality captured automatically when the sprint began. Success probability is derived from remaining work versus remaining capacity/time.

Example. Sprint 42 is on day 7 of a 10-day sprint. 30 of 50 committed points are done, but 12 points were added on day 4. Sprint Health reads 55 · At risk, success probability 48%, predicted carry-over ~14 pts, scope creep 24%. A warning reads "Scope added mid-sprint outpaces completion." The diagnosis writes itself: the team isn't slow, the sprint was expanded.

Act on it. High carry-over + high creep → stop adding scope. Low success probability with low creep → the plan was too big; re-plan or de-scope.

5.3 Release Readiness

• Answers: Is this release safe to ship? What's blocking it?
• Where: Project page → Release Readiness (uses the next unreleased version). Also works on a version/release panel.

What you see. The version name with a recommendation lozenge — GO, CONDITIONAL, or NO-GO — a confidence score, the release date (if set), whether the release contains blocked work, and a plain-language rationale. Risks appear as messages. A release gate checklist lists each gate with a pass / fail / manual status and a detail line.

How it's calculated. The confidence score runs a risk engine over the version's scope: unfinished work, blocked items, overdue timing, and completeness. Gates that Jira can verify (e.g. "all issues resolved," "no blockers") are marked pass/fail automatically; gates the app can't verify are marked manual for a human to confirm — never silently passed.

Example. Version 2.4 is due Friday. The checklist shows: All stories resolved → fail (3 open), No blocked issues → fail (1 blocked), Release notes written → manual. Recommendation: NO-GO, confidence 34 · Low. You know exactly what to clear before shipping.

Act on it. Clear the failing verifiable gates first; confirm the manual gates; re-check. A CONDITIONAL with only manual gates outstanding is usually a "sign-off and ship."

5.4 Dependency Radar

• Answers: What's blocking us, how bad is it, and what will it take down?
• Where: Project page → Dependency Radar.

What you see. A Dependency Health score, counts of active blockers, aging, and SLA-breached items, and a one-line summary (active / aging / stale / cross-team / breached). A score breakdown card explains the number. Auto-escalation surfaces blockers past SLA. A table lists each blocker with its SLA status, age, blast radius (how many items it blocks), and flags (aging, stale, cross-team, cross-project).

How it's calculated. Sprint Reality builds a dependency graph from Jira issue links, computes each blocker's blast radius, ages it against SLA thresholds, and scores overall dependency health from the volume and severity of open blocks. This view pages through all matching issues so blast-radius and SLA counts are complete (not a sample).

Example. Blocker PLAT-88 ("Auth service migration") shows blast radius 9, age 12 days, SLA breached, flag cross-team. Dependency Health is 41 · At risk and PLAT-88 is auto-escalated. One cross-team ticket is holding up nine of yours — that's your single highest-leverage fix.

Act on it. Sort by blast radius: the biggest-radius breached blocker is where escalation buys the most. Cross-team flags tell you when to escalate outside your team.

5.5 Delivery Analytics

• Answers: How does work actually flow through our process? Where does it get stuck?
• Where: Project page → Analytics.

What you see. A Delivery flow card with sample size, completed count, throughput per week, and lead time / cycle time summaries (p50 / p85 / average, with the sample count). A Bottlenecks table ranks the slowest statuses by average and total days. A Weekly trend table shows throughput and cycle-time p50 over recent weeks.

How it's calculated. Sprint Reality reconstructs each issue's history from the Jira changelog, maps statuses to categories, and measures time-in-status, lead time (created → done) and cycle time (in-progress → done). It reports the sample size and honest notes; it does not impute metrics for issues that lack history. This view is diagnostic — it is deliberately not folded into the delivery score.

Example. Cycle time p50 is 4d but p85 is 19d, and the Bottlenecks table shows Code Review averaging 6.2 days. Half your work flows fine; the long tail is stuck in review. The fix is a review-WIP policy, not "work faster."

Act on it. Compare p50 vs p85 to spot a long tail; use Bottlenecks to find the status causing it.

6. Planning & capacity

6.1 Capacity Planner

• Answers: How much real focus time does the team have this sprint?
• Where: Project page → Capacity.

What you see. A Capacity availability score, and metrics for availability %, focus hours, nominal hours, and (if you provide committed hours) utilization. A score breakdown card, and a per-member capacity table (nominal / holiday / PTO / meetings / focus hours per person).

How it's calculated. For each member, Sprint Reality starts from their working pattern (nominal hours), subtracts holidays, PTO/leave and events you've configured, and arrives at focus hours. Availability = focus ÷ nominal. Meeting load is an explicit "not connected" source until a calendar integration is added (on the roadmap) — it is shown as excluded, never estimated.

Example. A 5-person team has 200 nominal hours next sprint. Two developers each take 2 days PTO and there's one public holiday. Focus hours land at 146, availability 73%. If you also entered 160 committed hours, utilization reads 110% — a clear over-commitment signal before the sprint even starts.

Act on it. Use availability to size the sprint. Utilization over 100% means you've committed more than the team can focus on.

Configure (Editor/Admin): enter the team roster, working patterns and PTO in Capacity settings so the numbers reflect reality.

6.2 Resource Forecasting

• Answers: Will current staffing clear the backlog? Where are the skill gaps?
• Where: Project page → Resource Forecasting.

What you see. A resource forecast with a plain-language summary and metrics such as additional people needed, weeks to clear the backlog at current velocity, and velocity per person. A skills-gap table (per component: open work, recent throughput, contributors, gap score) and a future capacity table (projected weekly focus hours).

How it's calculated. Sprint Reality measures your actual velocity (resolved points ÷ window) and per-component load from Jira, projects future capacity over upcoming weeks (including scheduled absences), and compares required-vs-current velocity to estimate hiring need. The only assumption is the target horizon you choose — everything else is measured.

Example. The backlog holds 240 points. Measured velocity is 20 pts/week across 4 developers (5 pts/person). Forecast: weeks to clear ≈ 12, additional people ≈ 2 to hit an 8-week target. The skills-gap table flags Payments as a gap: 60 open points, one contributor. Hiring two generalists won't help Payments — you need that specific skill.

Act on it. Use weeks-to-clear for realistic commitments; use the skills-gap table to target what to hire, not just how many.

6.3 Predictive Simulation

• Answers: What happens if scope, velocity or a dependency changes — before we commit?
• Where: Project page → Simulation.

What you see. A what-if form with three inputs: scope Δ (points), velocity factor (e.g. 0.8 for a 20% slowdown), and dependency delay (days). Running it produces a sprint projection (success probability before vs after, carry-over Δ) and a capacity projection (focus hours before vs after), plus a plain-language scenario summary.

How it's calculated. The engine composes the real capacity model (hours, PTO/team changes) with the sprint burn-rate model (points, velocity factor, dependency delay) against your active sprint's actual baseline. The knobs are your inputs — nothing is invented — and points and hours are never silently converted into one another.

Example. "What if we add 8 points and a key integration slips 3 days?" You enter scope Δ +8, dependency delay 3. Result: success probability 61% → 39%, carry-over +9 pts. Now you can decide before committing whether to push the integration, drop scope, or accept the risk.

Act on it. Run the scenario you're actually considering in planning; use the before/after delta to make the trade-off explicit to stakeholders.

6.4 Delivery Cost Intelligence

• Answers: What is this sprint costing, and what are delays and blocked work costing us?
• Where: Project page → Delivery Cost.

What you see. A Delivery cost card with sprint cost, weekly burn, delay cost, and blocked-work cost, plus a cost trend table over recent weeks. If no rate is configured, the card clearly says "rate not set" and shows no fabricated figure.

How it's calculated. Cost = capacity focus hours × your configured blended hourly rate. Delay cost = overdue weeks × weekly burn. Blocked-work cost = blocked share of the sprint × sprint cost. There is no points-to-money conversion — everything is grounded in real hours and the rate you set.

Example. With a blended rate of $110/hr and 146 focus hours, sprint cost is $16,060, weekly burn $8,030. The release is 1 week overdue → delay cost $8,030, and 20% of work is blocked → blocked-work cost $3,212. Suddenly "the blocker is low priority" is a $3k/sprint conversation.

Act on it. Use blocked-work and delay cost to justify unblocking work in money terms leadership understands.

Configure (Admin): set the blended hourly rate in Delivery Cost settings. Without it, cost is honestly reported as unavailable.

7. Quality & people

7.1 Requirements Quality

• Answers: Are our stories well-formed enough to build reliably?
• Where: Project page → Requirements Quality (project aggregate) and the Story Quality issue panel (per issue).

What you see. Project view: an average quality score, a needs- attention count, the number of issues scored, an issue-breakdown by problem type, and a worst-scoring issues table. Issue panel: the single story's quality score, its specific problems, and improvement suggestions.

How it's calculated. Each story is scored across five dimensions: estimate present, description present, acceptance criteria present, right-sized (not oversized), and dependency-linked. Acceptance-criteria detection and description text are extracted from the issue's rich-text content. Improvement suggestions are suggestions only — they are never written back to Jira automatically.

Example. Story SR-210 scores 40: no estimate, no acceptance criteria, and it's oversized (21 points). The panel suggests: "Add acceptance criteria," "Add an estimate," "Split — 21 points is likely more than one sprint." The project view shows "Missing acceptance criteria" is your most common defect across 18 issues — a backlog-refinement focus for the week.

Act on it. Use the worst-scoring table to prioritise refinement; use the issue panel during grooming as a checklist.

7.2 Technical Debt

• Answers: How much debt are we carrying, and where is it concentrated?
• Where: Project page → Technical Debt.

What you see. A Technical Debt score, and counts of open debt items, reopened bugs, stale epics, and a net trend (growing/shrinking). A score breakdown, a list of the stalest epics, and a legacy components table (per component: open bugs, debt issues, reopened, debt index).

How it's calculated. The debt score weighs open debt-labelled work, bug reopen rate (reconstructed from the changelog as Done → not-Done transitions), stale epics, and a per-component debt index. The weekly trend shows whether debt is accumulating or being paid down.

Example. Technical Debt reads 48 · At risk, with 7 reopened bugs last month and the Legacy Import component carrying a debt index of 31 (12 open bugs, 4 reopens). Net trend +6 — debt is growing. The single component driving it is obvious, and the reopen rate says quality, not volume, is the problem.

Act on it. Target the highest debt-index component; a rising reopen rate is a signal to invest in test coverage there.

7.3 Engineering Credit Score™

• Answers: What's our overall, transparent delivery-health grade — and is it improving?
• Where: Project page → Engineering Credit.

What you see. A letter grade and a 0–100 score with confidence, a trend vs last indicator (▲/▼/▬), and how many days of history exist. A score breakdown shows each contributing factor and weight.

How it's calculated. A meta-score composing Delivery (35%), Technical Debt (25%), Requirements Quality (20%) and Dependencies (20%). Missing inputs are excluded and the weights re-normalised (with a caveat), so the grade is never propped up by an assumed value. A per-day history is stored (real values only) to compute the trend.

Example. This month the project is a B (74), up ▲+5 from last week — driven by requirements quality improving after a refinement push, even though dependency health dipped. Because every factor is shown with its weight, the grade is a conversation starter, not a mystery number.

Act on it. Use the factor breakdown to see which lever moved the grade; use the trend to confirm an initiative is working.

7.4 Team Health

• Answers: Is the team's workload sustainable? Who's at risk of burnout?
• Where: Project page → Team Health.

What you see. A Team Delivery Health score, unplanned-work %, an over-WIP count (people juggling too much), optionally meeting-overloaded, and a burnout-risk count. A score breakdown, and a team members table (per person: WIP, distinct projects, unplanned %, burnout level low/med/high).

How it's calculated. The score weighs WIP (40%), planned-work ratio (35%) and focus (25%). Burnout indicators are explainable — driven by high WIP, context-switching across many projects, and a high unplanned-work ratio (bugs/incidents). This view reads Jira assignments and types directly; no changelog needed. Meeting overload is included only when a calendar source is connected (roadmap) — otherwise it's excluded and noted.

Example. Team Health is 52 · At risk, unplanned work 38%. The member table shows J. Rivera: WIP 9, across 4 projects, unplanned 61%, burnout high. The score isn't a vibe — you can point to the exact person and the three drivers behind the flag.

Act on it. Reduce WIP and context-switching for anyone flagged high; a high team-wide unplanned ratio points at intake/triage, not individuals.

8. Intelligence & reporting

8.1 Decision Log

• Answers: What was decided, when, and by whom?
• Where: Project page → Decision Log.

What you see. A search box and counts of decisions by type (release, scope, status…), then a table of extracted decisions: date, issue, type, decision, and who.

How it's calculated. Sprint Reality reconstructs decisions from Jira history: sprint changes → scope decisions, fix-version changes → release decisions, story-point changes → estimate decisions, and status transitions → approved/rejected/done decisions. It also picks up explicit decision markers in comments and descriptions. Everything is derived — nothing is manually logged.

Example. Searching "payments" surfaces: 2026-05-02 · SR-88 · scope-change · "Moved out of Sprint 41" · by A. Khan and 2026-05-06 · SR-88 · release · "Retargeted to 2.5" · by A. Khan. A month later, when someone asks "why did payments slip?", the trail is right there.

Act on it. Use it for retro prep and stakeholder questions — an auditable record of scope/release/estimate changes without anyone maintaining a spreadsheet.

8.2 AI Delivery Advisor

• Answers: In plain language — what are the root causes, and what should we do?
• Where: Project page → AI Advisor.

What you see. An executive summary, root causes, why these risks exist, and prioritised recommendations — each finding citing the exact data it used. A narrative card shows whether the text is deterministic (rule-based) or AI-generated, and which model.

How it's calculated. The advisor's core is fully deterministic: it derives root causes, risk explanations and recommendations from the same real data as the scores, and every finding lists its evidence. If an admin connects the optional AI layer, the LLM only rephrases those grounded findings into smoother prose — it adds no new facts and takes no action. Without AI, you still get the complete deterministic advisory, clearly labelled "rule-based."

Example. The advisor summarises: "Delivery is at risk primarily due to mid-sprint scope growth (24%) and one breached cross-team blocker (PLAT-88, blast radius 9)." Recommendation 1: "Freeze scope for the remainder of Sprint 42 — evidence: 12 pts added on day 4." Every claim points back to a number you can verify.

Act on it. Read the recommendations top-down (they're prioritised); use the cited evidence to defend the action in planning.

8.3 AI Project Investigator

• Answers: Ask a plain-English question, get a grounded, cited answer.
• Where: Project page → AI Investigator.

What you see. A question box with one-click suggestions, and an answer card showing the detected intent, the answer, its confidence, and the evidence it's based on.

How it's calculated. The investigator recognises a set of canonical delivery questions and routes each to the authentic source (release rollup, dependency graph, team-health, capacity what-if) to build a grounded, cited answer. It is deterministic — the same question over the same data gives the same answer.

The canonical questions:

• "Why is this release late?"
• "Which dependency is highest risk?"
• "What should we fix first?"
• "Which team is overloaded?"
• "What happens if we remove a developer?"

Example. Ask "What happens if we remove a developer?" The investigator runs a capacity what-if and answers: "Removing one developer drops focus hours ~29 (from 146 to 117) and lowers this sprint's success probability from 61% to ~44%. (Representative example using an average contributor.)" — with the capacity figures as evidence.

Act on it. Great for quick stakeholder answers; the cited evidence links the answer back to the underlying view if you want detail.

8.4 Smart Digest

• Answers: Keep everyone updated without a meeting.
• Where: Project page → Smart Digest (configure, preview, send); scheduled delivery to Slack / Teams / email.

What you see. A Delivery settings card (admins): a schedule on/off toggle, Daily / Weekly selectors, Slack and Microsoft Teams webhook fields, and an email recipients field. A Preview & send card builds the digest from live data (Preview) or delivers it now to the configured channels (Send now). Delivery results show per channel (sent / not-sent with reason).

How it's calculated. The digest composes the current delivery status (health, risks, key numbers) into a text summary and renders it for plain text, Markdown, Slack and Teams. Scheduled daily/weekly runs send automatically to every enabled project. Delivery is honest: if a channel isn't configured, or email isn't set up, it reports not-sent with a reason — it never pretends to have sent.

Example. An admin turns Scheduled delivery on, selects Daily, pastes a Slack incoming-webhook URL, and clicks Save settings, then Send now to test. Slack shows ✓ sent; email shows ✗ email provider not configured (because no sender is set up yet) — exactly what's true.

Act on it. Set a daily digest to a team channel for passive awareness; use weekly to a leadership channel for the roll-up.

Configure (Admin): enter channels in Delivery settings. Slack/Teams need only an incoming-webhook URL. Email additionally needs the app-level sender configured by your Forge admin (see Optional integrations).

9. Organization-wide

9.1 Portfolio Intelligence

• Answers: How healthy is the whole portfolio, and where's the cross-team risk?
• Where: Global page → Portfolio Intelligence.

What you see. A portfolio health score, on-track %, cross-project blockers, escalations, and an outlook (improving / stable / declining / at-risk). A score breakdown, program roll-ups, and a projects table (per project: health, on-track, cross-project blockers, escalations).

How it's calculated. Portfolio health aggregates the per-project delivery scores (each computed exactly as on its own Dashboard, and permission-checked). Cross-team risk sums cross-project blockers and escalations; the forecast derives the outlook from the on-track ratio and its trend.

Example. Across 6 projects, portfolio health is 66, on-track 67%, outlook declining, with 4 cross-project blockers. The projects table highlights Checkout at 38 dragging the average. You steer attention to Checkout without opening six dashboards.

Act on it. Sort the projects table by health to find where leadership attention pays off most; watch the outlook for early warning.

Configure (Admin): add the project keys that make up the portfolio in the portfolio configuration.

9.2 Dependency Heatmap

• Answers: Which teams block which, across the organization?
• Where: Global page → Dependency Heatmap.

What you see. Headline counts of cross-team dependencies and teams, a top blocking teams list, a team risk map (per team: risk score, open blocks, open deps), and the full team-to-team dependency matrix (dependent team → blocker team, open / total).

How it's calculated. Sprint Reality reads the dependency graph across all portfolio projects and rolls links up to the team level (from the team field), excluding same-team and unknown-team edges (which it counts separately). Risk score weights open blocks and how many teams a team is blocking.

Example. The matrix shows Platform is the top blocking team: it's blocking 5 other teams with 11 open cross-team dependencies, risk score 27. That's an org-level staffing/prioritisation conversation about the Platform team, visible in one grid.

Act on it. A single team topping the blocking list is usually an org bottleneck — a signal for capacity or prioritisation changes at that team.

10. Administration

10.1 Roles & permissions (Enterprise)

• Where: Project page → Enterprise.

What you see. Your current app role, the explicit role assignments for the project, and (for admins) the audit log.

How it works. Roles are viewer / editor / admin, layered on Jira. Absent an explicit assignment, your role is derived from your Jira level (project admin → admin, otherwise viewer). An admin can raise someone to editor/admin or downgrade a Jira admin to viewer to restrict them inside Sprint Reality — but no one can ever get a role on a project they can't see in Jira.

Example. A team lead who is not a Jira project admin needs to manage digest channels. An admin assigns them Editor on the project — now they can edit settings and send digests, but still can't set cost rates or manage roles.

10.2 Audit log

• Where: Project page → Enterprise (admins only; requires the audit-view permission).

What you see. An append-only log of sensitive actions: when, who, action, and target. Configuration writes and delivery sends are recorded.

How it works. Every write through the RBAC-gated resolvers — saving capacity, digest or cost settings, sending a digest, changing roles — records an audit event. Secrets (webhook URLs, API keys) are never written to the log; only the action and safe details (e.g. "enabled=true", "period=daily").

Example. The log shows 2026-06-30 14:05 · u_ab12 · digest.settings.saved · enabled=true and …· cost.config.saved. If a rate or channel changes unexpectedly, you can see who changed it and when.

10.3 Settings you can configure

11. Optional integrations & setup

Everything below is off by default and enabled by an admin adding a credential — in keeping with least-privilege. The app is fully functional without any of them.

Data note. Data leaves Atlassian only when one of these is enabled, and only the content of that integration (a digest summary, or the advisor's findings). See the Privacy Policy for full detail.

12. "Why is my number missing?" — the trust rule in practice

A blank, "excluded," or "not connected" is Sprint Reality telling you the truth. Common cases:

The principle: exclude, disclose, and cap confidence — never fabricate.

13. Roadmap

Clearly-labelled future work, not part of the current feature set:

• Meeting-aware capacity — connect a team calendar (Google / Outlook / Microsoft 365) so Capacity and Team Health can subtract real meeting load from focus hours. Today meeting load is shown as "not connected" and excluded from the score rather than estimated.

14. FAQ & troubleshooting

Does Sprint Reality change anything in my Jira? No. It requests read-only access and never writes to or acts on your issues — including the AI features, which only explain.

Do I need to add custom fields or change our process? No. It reads the Jira you already have. More configuration (rates, roster, channels) unlocks more views, but the core works on day one.

Why is a score lower/higher than I expect? Open its score breakdown — the formula, each weighted factor, and any caveats are all shown. If confidence is Medium/Low, a factor was excluded; the caveat says which.

A view says "capped" or "understated." Is the data wrong? No — it's honest. A Jira search hit its page limit, so the count is a floor and is flagged. Narrow the query for an exact count.

Can non-admins use it? Yes. Viewers see all analytics. Editing settings and sending digests needs Editor; rates, roles and the audit log need Admin.

Email digests aren't sending. Check that your Forge admin has set RESEND_API_KEY and DIGEST_FROM_EMAIL, and that the sender domain is verified in Resend (DNS/SPF/DKIM). Slack/Teams need only a webhook URL. The delivery result shows the exact reason for a non-send.

The AI Advisor says "rule-based" — is AI broken? No — it means no AI key is configured, so you're seeing the complete deterministic narrative. AI phrasing is optional.

15. Support

• Support: support@helpingbrains.info
• Sales enquiries: sales@helpingbrains.info
• Provider: Helping Brains — https://helpingbrains.info

Sprint Reality is built on Atlassian Forge and runs entirely on Atlassian-hosted infrastructure; your Jira data is processed inside Forge and is not stored on external servers.