Daily Standup Starter

Plan the day, do not report on it

The daily standup is the team's shortest planning session. Frankee reads your tracker beforehand and hands you what the team needs in order to plan: what the day should focus on, what is genuinely in the way, and where yesterday changed the picture.

What the standup is actually for

The most common mistake in agile practice is running the daily standup as a status meeting. Each person reports to a Scrum Master, everyone else waits their turn, and the event becomes a progress audit that the board could have answered on its own.

It is meant to do three things, and none of them is reporting:

• Align on priorities. Agree the most important work for today and how each person's piece moves the team toward the target.
• Surface blockers. Name obstacles, risks, and missing information early, while they are still cheap to resolve.
• Adapt the plan. Change what the team does next based on what yesterday actually taught you.

Status recitation crowds all three out. It fills the timebox with information the board already holds, and the real conversation gets pushed into a smaller meeting afterwards. Frankee exists to take that reconstruction off the table so the fifteen minutes can be spent deciding rather than describing.

How the briefing serves each purpose

Aligning on priorities

Every briefing opens with one to three specific recommendations for today, drawn from the day's signals and naming real work and real people. Not "watch out for blockers", but which item, whose plate, and what to do about it. This is the section to start the meeting from.

Frankee builds it from things that are hard to see in a board glance:

• Workload distribution. Who is carrying more in-flight work than your per-person limit, and who has capacity to pick something up. Where it sees both, it suggests the redistribution by name.
• Priority inversions. High-priority work still sitting untouched while lower-priority items are being worked. This is the single most common way a team's day drifts from its intent.
• Work with nobody's name on it. In-progress items with no assignee, usually a handover that did not complete.
• Deadline pressure. For continuous-flow teams, high-priority work that is overdue or lands within the week.

Surfacing blockers

The blockers that hurt are rarely the ones someone announces. They are the ones that went quiet. Frankee measures time rather than waiting for a volunteer:

• Stuck work. Items that have not changed state for longer than your team's threshold, with the number of days attached. Nobody puts their hand up to say a ticket has not moved in five days, so this is the section most teams find earns the tool.
• Declared blockers. Whatever your tracker already reports as blocked, so it does not get lost among everything else.
• Silence. Items with no discussion for longer than your inactivity threshold. Work with no conversation around it is often work that quietly stalled.
• Queues. Columns holding more work than they should, which turns a scattered set of delays into one visible bottleneck.

Each of these is an invitation to ask what is in the way. None of them is a conclusion about why.

Adapting the plan

Adapting means changing the plan when yesterday says you should, which requires knowing where you actually stand:

• Pace against expectation. For sprint teams, work completed compared with a straight-line pace for the day you are on. This is what turns "we finished twelve points" into "we are behind, and we should decide something".
• Carry-over. Work brought forward from a previous sprint, which blends into the board and stops being questioned.
• Work at risk. What is unlikely to land, framed against your sprint or your due dates, while there is still time to change course.
• One question worth raising. Every briefing ends with a single question chosen from the day's signals. It is there to produce a decision, which is what separates a planning session from a progress report.

Generating a briefing

Go to Team Events › Daily Standup Starter, pick your team, and press Generate. It reads your tracker live and takes a few seconds. Generate shortly before the meeting so the picture is current.

Generation is manual, every time. Nothing runs on a schedule and nothing is emailed or posted to chat. Frankee also never presents yesterday's briefing as today's: opening the page shows your history, and today's briefing appears only once you generate it. A stale briefing shown as current would be worse than no briefing at all.

Past briefings are listed underneath, which is useful when a pattern has been building for a week rather than a day.

The underlying picture

Alongside the analysis, the briefing lists what completed, what is in progress, what has not started, and what is blocked. That is context to refer to when a question comes up, not an agenda to work through. If your standup consists of reading these four lists aloud, the tool has been turned back into the problem it was meant to remove.

Scrum and Kanban read differently

The two frameworks give a team different things to plan around, so Frankee fetches different signals. You do not configure this: it follows your team's framework setting.

Scrum teams

The briefing is built around the active sprint, and adds what only a sprint makes meaningful:

• Sprint position. Which day of the sprint you are on, out of how many.
• Burn against expectation. Completed work compared with a straight-line pace for that day.
• Carry-over from previous sprints.
• Priority inversions within the sprint scope.

With no active sprint, the briefing says so rather than reporting an empty board as a quiet day.

Kanban teams

There is no sprint to measure against, so the briefing reads the board itself:

• Column work in progress. Frankee loads your board's actual column configuration and counts what sits in each, so a bottleneck shows up as a column rather than a list. Done and terminal columns are excluded.
• Dwell time. How long each item has been in its current column, taken from the board's own record of status changes. This is what makes stuck detection meaningful without a sprint boundary. Where that history is unavailable, Frankee falls back to when the item was last updated and tells you the age is approximate rather than presenting an estimate as fact.
• Upcoming due dates. High-priority items in to-do that are overdue or due within seven days. This needs your team's high-priority values configured; without them Frankee reports the signal as unavailable instead of quietly omitting it.

Azure DevOps teams

Azure DevOps standups read your team's current iteration, so they need a sprint-based team. Continuous-flow Azure DevOps teams are not supported yet and are told so directly rather than handed an empty briefing. Item ageing comes from the date each work item last changed state.

Settings that shape it

These live under Settings › Team Setup in Standup Settings, and tuning them is what keeps the briefing worth reading:

• Stuck threshold. Days without movement before work counts as stuck. Lower it if the section is empty every day; raise it if everything is flagged. A briefing that always cries wolf gets ignored.
• Comment inactivity threshold. How long without discussion before an item is called stale.
• Work in progress limits. Per person and for the team. These drive the redistribution suggestions.
• High priority values. Which priority names your tracker uses for urgent work.

If something is missing

• "No integration connected." A tracker has to be connected at the organization level first. See Integrations.
• Project key or board not configured. Jira standups are board-scoped, so a team needs both its project key and its board ID in Team Setup.
• Nothing in the stuck section. Usually good news, occasionally a threshold set too high.