How to track bug and feature status from your standups

Standups are where a bug's real status is said out loud: fixed on staging, waiting on the client, not reproducible. This guide is for developers, tech leads and project leads who run daily or weekly standups on Google Meet or Microsoft Teams and want each bug and feature's status kept in one table, updated after every standup, with the words that changed it. It covers the columns, how a status column with final options behaves, how blockers come and go, and what the table does not do.

Why does what is said in standups drift from the issue tracker?

Because saying "the checkout fix is on staging" takes five seconds and moving the ticket takes a context switch nobody makes during a standup. The issue tracker shows what someone last clicked; the standup knows what is actually true.

The gap is widest on client projects. Half of the status lives in the client's own issue tracker, which you may not be able to edit, and the other half lives in what their team said on the call. A table of what each standup said, with who said it, closes that gap without asking anyone to update anything during the meeting.

How do you set up a table for bug and feature status?

Start from the Project tracker template, one of six TrackHeros offers. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. A tracker is a table that fills itself from those meetings: you choose which ones, and after each, TrackHeros reads it and proposes changes.

Column	Type	What goes in it
Item	Text, names the row	One row per bug, feature or task
Description	Text	One sentence, as described in the meeting
Status	Status	Where it stands, only when the meeting says so; the latest value wins
Owner	Person	Left empty if nobody was named
Deadline	Date	A stated or agreed date, not a duration
Priority	Status	Low, Medium, High, only when someone says so
Blockers	List	Added when raised, removed when resolved
Last discussed	Automatic	The last meeting that mentioned the row

Each column carries a one-line description, and that is what TrackHeros reads to decide what belongs in a cell. It is told to fill only what the meeting actually says, so a bug mentioned without a status keeps its old one.

What does a status column with final options do?

A status column holds one of a set of options you define, and some of them can be marked final. In the template the options are Not started, In progress, Blocked, In review, Done and Dropped, with Done and Dropped final.

Marking an option final tells TrackHeros the row is finished rather than in motion. The row stays in the table with its whole history. If a later standup says a finished bug is back, the new status is proposed like any other change, with the quote behind it.

Your team may use other words, so rename the options and choose which are final. A bug-focused status column might read Reported, Reproduced, Fixing, Fixed on staging, Released and Won't fix, with Released and Won't fix final. Adding, removing or retyping a template's columns counts as designing your own tracker; pricing says which plans include that.

What does a week of standups look like in one row?

Every change to the row is kept, with the standup it came from, who said it and the words they used. Here is one bug across three standups with a fintech client:

Standup	Change	Words used
Monday 9 February 2026	Status: In progress. Blockers: added "sandbox logs"	Anil: "I'm on the checkout timeout, but I need the sandbox logs from the payment provider."
Wednesday 11 February 2026	Status: In review. Blockers: removed "sandbox logs"	Anil: "Got the logs. The fix is up for review."
Friday 13 February 2026	Status: Done	Meera: "The checkout timeout fix is merged and verified on staging."

A link beside each entry opens the transcript at that moment, and the recording jumps there. The quote is rebuilt from the stored transcript, never written by the model, and a value with no transcript line behind it is dropped.

How does each bug keep one row across standups?

Rows are named by the key column, here Item. When a later standup mentions the same bug, its row is updated rather than duplicated. When a new row looks like an existing one, "checkout timeouts" against "Checkout timeout on slow networks", it is flagged as a possible match for you to settle: the same row, or a new one.

Rows are never merged automatically, because two bugs with similar names are often two bugs. Answering same as keeps the new row's history under the existing row. Naming a bug the same way at each standup, or saying its ticket number, makes the match easier for everyone, TrackHeros included.

How are blockers tracked?

As a list. A blocker is added when it is raised and removed when someone says it is resolved, so the Blockers cell always shows what is still in the way, and its history shows how long each item sat there.

Removing an item from a list always waits for a person, even when a tracker is set to apply confident changes on its own. "We're fine on the logs now" is easy to mishear, and a blocker that vanished by mistake is worse than one that stayed a day too long.

Should you keep a standup log or a status table?

They answer different questions. The Standup log template adds one row per standup: date, attendees, done, planned and blockers, which is the record of each meeting. The Project tracker keeps one row per bug or feature and updates it, which is the record of each piece of work.

If you want to know what happened on Wednesday, read the log. If you want to know where the checkout fix stands, read the status table. A standup tracker for developers covers the log, and one row per meeting or one table that updates covers the choice.

Where do you see what changed after a standup?

In three places. Each meeting's page has a "What changed" panel listing what that standup gave each tracker. The tracker's review tab holds new and changed values, grouped by meeting, to accept, edit then accept, or reject. And the table can be filtered to rows that changed recently, changed several times, have conflicts or are waiting for review.

The tracker's creator gets an in-app alert when changes are waiting. The table fills after the meeting's notes are ready, not during the call, and very short meetings are skipped. A standup held partly in Hindi and partly in English is read through the same transcript as the notes, after its audio pass; the languages page lists the close to 100 spoken languages TrackHeros recognises.

Does it update your issue tracker?

No. A tracker does not send rows to an issue tracker, and it does not read ticket status from one. It records what was said in your meetings, in its own table inside the client's workspace.

That separation is useful: the table is evidence of what the team said, kept apart from what the ticket says. When the two disagree, that is a question for the next standup. The table and its full history can be downloaded as CSV; pricing says which plans include export. For the rest of what trackers do, see the Trackers feature; for how TrackHeros fits a developer's week of client calls, see freelance developers.