Mid-sprint: are we going to make it?

We are in the middle of the sprint and I need to know now, not on the last day, whether we are going to deliver what we committed to. ## Context - Squad: [squad] - Sprint day: [for example day 6 of 10]. DevStats does not know the sprint dates, so this has to come from me. - Unit: [issues | story points] - If something has to go, I would rather descope today than explain a miss at the review. - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats 1. Sprint Progress — To Do / In Progress / Done for the active sprint, in the unit above If there is no active sprint, stop here and tell me. Between sprints there is nothing to descope. Offer the same read on the sprint that just closed, as input for the next planning. 2. Sprints for the last 90 days — committed vs completed per sprint. This is our real completion rate. 3. Planning Accuracy for the last 90 days 4. Issue Cycle Time for the last 90 days — how long an issue takes once it starts 5. Issue List with status in_progress, sorted by activated_at ascending, fields key, summary, project, story_points, activated_at, history 6. Aging Issues and Open PRs — what is stuck right now 7. Daily WIP for the last 14 days — is work in flight growing or shrinking ## How to analyze - Compare Done % with the share of the sprint already elapsed. Work lands late in a sprint, so being 10 to 15 points behind the calendar is normal. More than 20 behind is not. - Judge the commitment against our own history, not against 100%. If we usually complete 70% of what we commit, a sprint heading to 70% is a normal sprint with a planning problem, not a delivery crisis. Say which one this is. - In Progress above half of the sprint with Done below a quarter means too much was started at once. The fix is to stop starting, not to push harder. - Any issue in progress for longer than our average issue cycle time is unlikely to finish on its own. List them and say what they are waiting for, using the status history. - Any To Do item not started yet needs the average cycle time to fit in the days left. If it does not fit, it is a descope candidate, not a stretch goal. - An in-progress issue with an open PR in review is close. One with no PR is not. Use Open PRs to tell them apart. ## Deliver 1. **Verdict** — on track, at risk, or will miss, in one sentence with the two numbers that justify it. 2. **Forecast** — three short lists: will land, at risk (and what each one needs), will not make it. 3. **Descope today** — which items to pull out of the sprint now and why those, plus anything to stop starting. 4. **Message to stakeholders** — three sentences I can send today: where we are, what changes, what they still get. 5. **For the next planning** — one adjustment to the commitment size or the way we slice work, backed by the sprint history.