BLOCKER Don't lose the CI failure in the daily
This pull request is blocked by a failed CI run.
Ask: Is the CI fix clear, or does the author need help right away?
Sources: ci | repo
Engineering intelligence Operative clarity for Tech Leads and Scrum Masters
Scrum doesn't need
guesswork.
Your tools already know what is stuck. Scrum-OS brings it to the surface before the daily, so the team walks in with the questions already asked. The cockpit below is Thursday morning of a demo team.
Join the waitlist See what surfaces
6 months free at launch.
Team cockpit | Lead Bottleneck Sample data, not a real team.
REV | Review Hub Thursday | 09:15
CI red | Thu 09:15
-
Flow risks
2
PRs or tickets need a decision today.
-
CI
1 red Blocks merge
Required check blocks the merge of fix/rev-101-timezone-activity-filter | PR #1001.
-
Reviews
1
1 pull request has been waiting longer than 1 day for feedback.
-
Ops
PROD alert
review-hub-api looks off after a deployment.
-
Since last daily
8 events
3 developers active | 0 new PRs | 1 merge
-
Sprint goal
25% Tense
1 of 4 sprint items done
Reachable if the open flow risks are settled today.
Open reviews by permitted reviewer
3 of 3 open pull requests may only be reviewed by one person.
- MiraLead3 open reviews
- JonasBackup reviewer0 open reviews
- LeaAuthor0 open reviews
- NoahAuthor0 open reviews
Daily agenda
since daily WED 09:15
Today the team needs 3 decisions so flow doesn't tip.
A review stall, a red required check and an ops signal worth a look are the most important talking points from the event store.
-
-
REVIEW STALL Clear the review stall first
This pull request needs a review or a pairing decision.
Ask: Who takes the review today, or who helps the author directly?
Sources: repo | review
-
DEPLOY WATCH Watch the service after the deploy
The alert for review-hub-api lines up in time with a deployment.
Ask: Is the alert understood, or does someone look at the deploy today?
Sources: cd | monitor
7 sources analysed
One sprint week
Three mornings of the same team.
Same team, three consecutive dailies. Nothing here is dramatic: a review nobody picked up, a build left red overnight, a teammate who went quiet. Small things, and each one costs the sprint days before anyone says it out loud.
01 Wednesday | 09:15
One pull request has been waiting since Monday evening.
Lea opened it on Monday evening. The one person allowed to review it had a full Tuesday, and by Wednesday morning nobody has said anything about it. Scrum-OS puts it on the agenda with the branch, the number and how long it has been sitting there, so it gets asked about instead of remembered. Nobody has to be the one who brings it up.
- feature/rev-102-open-pr-filters | PR #1002 waiting 1d 15h without review activity
- No CI card and no ops card: there is nothing to report there yet, and the cockpit says so instead of filling the gap.
Team cockpit | Lead Bottleneck Sample data, not a real team.
REV | Review Hub Wednesday | 09:15
Synced | Wed 09:15
-
Flow risks
1
PRs or tickets need a decision today.
-
Reviews
1
1 pull request has been waiting longer than 1 day for feedback.
-
Since last daily
6 events
2 developers active | 2 new PRs | 0 merges
-
Sprint goal
0% Stable
0 of 4 sprint items done
Goal: make the review bottleneck around the lead visible and cut waiting times.
Daily agenda
since daily TUE 09:15
-
REVIEW STALL Clear the review stall first
This pull request needs a review or a pairing decision.
Ask: Who takes the review today, or who helps the author directly?
4 sources analysed
- No CI card: every run in the store so far reports success.
- No ops card: no deployment and no alert in the event store yet.
02 Thursday | 09:15
The review came, and the build stayed red overnight.
A comment on Wednesday afternoon, a fix pushed at 16:50, and the run after it failed at 17:15. Nothing has been pushed since, so this is a build nobody has picked up rather than one already being fixed. That difference is what the daily should spend its time on. A second review has been waiting since the same night, and an alert that followed Wednesday's deployment is still open.
- fix/rev-101-timezone-activity-filter | PR #1001 red for 16h, nothing pushed since
- refactor/rev-103-api-client-list-cleanup | PR #1003 waiting 1d 21h without review activity
Team cockpit | Lead Bottleneck Sample data, not a real team.
REV | Review Hub Thursday | 09:15
CI red | Thu 09:15
-
Flow risks
2
PRs or tickets need a decision today.
-
CI
1 red Blocks merge
Required check blocks the merge of fix/rev-101-timezone-activity-filter | PR #1001.
-
Reviews
1
1 pull request has been waiting longer than 1 day for feedback.
-
Ops
PROD alert
review-hub-api looks off after a deployment.
Daily agenda
since daily WED 09:15
-
BLOCKER Don't lose the CI failure in the daily
This pull request is blocked by a failed CI run.
Ask: Is the CI fix clear, or does the author need help right away?
-
REVIEW STALL Clear the review stall first
This pull request needs a review or a pairing decision.
Ask: Who takes the review today, or who helps the author directly?
-
DEPLOY WATCH Watch the service after the deploy
The alert for review-hub-api lines up in time with a deployment.
Ask: Is the alert understood, or does someone look at the deploy today?
7 sources analysed
03 Friday | 09:15
Someone has gone quiet, and that is worth a question.
Noah opened his pull request on Tuesday and nothing has come from him since. His one permitted reviewer never got to it, so there was nothing to answer and nothing to push. Scrum-OS does not read that as a performance problem and does not report it anywhere. It puts one line in the agenda so the lead can ask what is in the way, on Friday instead of next week.
- Noah, no recorded activity for more than two days
- refactor/rev-103-api-client-list-cleanup | PR #1003 on the agenda for the second daily in a row
Team cockpit | Lead Bottleneck Sample data, not a real team.
REV | Review Hub Friday | 09:15
Synced | Fri 09:15
-
Flow risks
1
PRs or tickets need a decision today.
-
Reviews
1
1 pull request has been waiting longer than 1 day for feedback.
-
Ops
PROD alert
review-hub-api looks off after a deployment.
-
Since last daily
8 events
3 developers active | 0 new PRs | 1 merge
Daily agenda
since daily THU 09:15
-
REVIEW STALL Clear the review stall first
This pull request needs a review or a pairing decision.
Ask: Who takes the review today, or who helps the author directly?
-
DEPLOY WATCH Watch the service after the deploy
The alert for review-hub-api lines up in time with a deployment.
Ask: Is the alert understood, or does someone look at the deploy today?
-
IDLE DEV Talk to the quiet developer
Noah has produced no visible activity for more than 2 days.
Ask: Blocker, context switch, or missing work packages?
6 sources analysed
- No CI card: no failing run open in the store.
Where the signals come from
Eight sources, one shared picture.
The signals are already there, scattered across eight tools that nobody watches all at once on a Tuesday afternoon. Scrum-OS collects them into one record, so the daily reads from what the team actually did rather than from what somebody remembered to mention.
Eight engineering sources, code repo, code review, issue tracker, CI, build server, CD, monitoring and documentation, all feeding one central event store.
Event store
- Code repoCommits & PRs
- Code reviewReviews & approvals
- Issue trackerTickets & sprint
- CIPipelines & checks
- Build serverBuilds & artifacts
- CDDeployments
- MonitoringAlerts & metrics
- DocumentationGoals & tasks
Every item in the cockpit points back to something that actually happened, with a timestamp. Nothing is summarised without one.
How it works
Connect once. After that it is simply there every morning.
Connect your stack
Plug in the repo, review tool, CI, issue tracker and monitoring your team already uses. Scrum-OS reads them. Nobody logs anything twice, and nobody has to change how they work.
Let it watch the flow
Scrum-OS follows the work, not the people: what is open, what is waiting, what is red. No score, no ranking, and nobody gets rated.
Walk in ready
The agenda is there before the meeting starts, sorted by what is holding things up. After the daily the same view stays open for the rest of the sprint.
Start with the daily. The same view carries through the rest of the sprint.
What surfaces
The things that only come up once they hurt.
Most of what slows a sprint down is not hidden. It is spread across five tools, and seeing it means noticing at the right moment. Scrum-OS watches the work instead, and puts what it finds on one page before the daily starts.
Work that has stopped moving
A change that has been open a while with nothing happening on it. Often it is not stuck at all, and finding that out takes ten seconds in the daily. Sometimes it is, and by then it has already cost a week.
A review nobody picked up
Waiting for a review is the quietest way a sprint loses days. Scrum-OS shows what is waiting and for how long, so asking about it is not a matter of who happened to notice.
A build left red
A failing check that nobody has pushed a fix for. If someone is already on it, it is not a topic for the daily. Telling those two apart is the point.
Work going round in circles
The same piece of work coming back again and again. That is almost never a careless author. It is usually a scope that was never really agreed, and it belongs in a conversation rather than in another round.
Someone who has gone quiet
No visible activity for a while. This is a question, never a verdict: blocked, pulled onto something else, or simply working somewhere Scrum-OS cannot see. The lead asks. Scrum-OS does not conclude.
None of this rates anyone. Every signal points at a piece of work, and if it is wrong, saying so in the daily is the whole correction.
Data
What Scrum-OS reads, and what it never touches.
A tool that connects to your repo has to answer this before a team will accept it. Here are our answers, written before you have to ask.
Read-only, always
Scrum-OS reads events from the systems you connect and writes nothing back: no comments, no labels, no status changes, no merges. Nobody's way of working changes because Scrum-OS was switched on.
Metadata, not your source code
Branch names, titles, authors, reviewers, timestamps, build results, ticket references. File contents and diffs are never ingested.
No scores, no rankings
Scrum-OS never rates a person and never produces a number about one. What it shows is a piece of work and how long it has been in that state.
Early access
Help shape the daily you'll actually run.
We are starting with the daily and building towards support that lasts the whole sprint. Early access means you see it while it is still open to argument, and what you say still changes it.
6 months free at launch.
- You join the list One email address is enough. The optional questions about your team and your tools take about a minute, and skipping them changes nothing about your place on the list.
- Your invite When your slot opens, we write once with your access link and a short setup guide for connecting a repo and a CI.
- Six months free Everyone on the waitlist gets the first six months after launch at no cost.
What happens next