# How to track bug and feature status from your standups

> For developers and project leads who discuss bugs and features in standups on Google Meet or Microsoft Teams: how to keep each one as a row that TrackHeros updates after every standup, with a status column whose options you define and some marked final, blockers that come and go, and the words behind each change. It records what was said; it does not update an issue tracker.

Canonical: https://trackheros.com/blog/track-bug-status-from-standups/  
Author: Sami Kanafani  
Updated: 2026-11-04

**In short:** TrackHeros can keep each bug or feature discussed in your Google Meet and Microsoft Teams standups as one row of a tracker, with a status column whose options you define, some marked final such as Done. After each standup, status changes and blockers are proposed with the quote behind them. The table records what was said; it does not update or read your issue tracker.

| Fact | Detail |
| --- | --- |
| Starting point | The Project tracker template: item, status, owner, deadline, priority, blockers |
| Status options | Defined per column; some can be marked final, such as Done or Dropped |
| Blockers | A list: added when raised, removed when said to be resolved |
| Issue tracker | Not updated and not read; the table records what was said in meetings |

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](/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](/blog/standup-tracker-for-developers/) covers the log, and [one row per meeting or one table that updates](/blog/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](/languages/) 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](/pricing/) says which plans include export. For the rest of what trackers do, see the [Trackers feature](/features/trackers/); for how TrackHeros fits a developer's week of client calls, see [freelance developers](/for/freelance-developers/).

## Frequently asked

**Does TrackHeros move the ticket when a standup says a bug is fixed?**

No. A tracker records what was said in the meeting, in its own table. It does not change tickets in an issue tracker and does not read their status. Use the table to see what the standup said, then update the ticket yourself.

**What happens to a bug marked Done that comes back?**

A final status marks the row as finished, but the row stays in the table with its history. If a later standup says the bug is back, the new status is proposed like any other change, with the quote that supports it.

**Will two names for the same bug create two rows?**

A new row that looks like an existing one is flagged as a possible match for you to settle: the same as an existing row, or a new one. Rows are never merged automatically; answering same as keeps the new row's history under the existing one.

---

TrackHeros is in early access: https://trackheros.com/#early-access