Measuring Retrospective Cycle Time in FogBugz (Kanban “Doing” → Closed) Using the XML API

Solution (XML API extraction + external calculation)

How it works (expected behavior)

When a case is dragged between Kanban columns (for example, into Doing and later into Done), FogBugz writes case events for those moves and stores timestamps for each event. These events (including their timestamps) can be retrieved via the FogBugz XML API.

Prerequisite: Create an API token

1. Sign in as a FogBugz admin user.
2. Open the Avatar menu (bottom-left).
3. Select User Options.
4. Create and copy an API token.

Step 1: Pull relevant cases and include event history

Use the FogBugz XML API search command and include cols=events so the response contains each case’s event stream.

General structure:

https://your_instance.domain.com/api.asp?cmd=search&q=...&cols=events&token=<your_api_token>

Example query (replace placeholders as needed):

• Base URL: https://your_instance.domain.com/api.asp
• Command: cmd=search
• Query: q=kanban:Done%20AND%20Doing
• Columns: cols=events
• Token: token=<your_api_token>

Full example URL (generalized):

https://your_instance.domain.com/api.asp?cmd=search&q=kanban:Done%20AND%20Doing&cols=events&token=<your_api_token>

Optional: Narrow the scope (project, milestone, etc.)

Add additional conditions to the q= parameter. Make sure spaces are URL-encoded (for example, as %20).

q=kanban:Done%20AND%20Doing%20AND%20project:<your_project>%20AND%20milestone:<your_milestone>

Step 2: Parse events to find when the case entered “Doing”

1. For each returned case, locate its <events> block.
2. Identify the relevant ixBugEvent entry (or entries) whose text indicates the case moved into Doing (the event text typically reflects the Kanban column change).
3. Record the timestamp (date/time) for that “entered Doing” event.

Step 3: Choose an “end” marker and calculate cycle time

Decide which end marker matches your reporting definition:

• Doing → Closed: use the case’s closure timestamp (if available in your pulled data) or use the event that indicates closure.
• Doing → Done: use the timestamp for the event that moved the case into Done.

Then compute:

cycle_time = end_timestamp - entered_doing_timestamp

This calculation is typically done externally (for example, in a spreadsheet, Python script, or BI tool) after parsing the event data returned by the API.

Step 4: Build the external report

For larger datasets, a typical reporting approach is:

• Collect the API output for the relevant closed cases.
• Parse only the events that represent Kanban column transitions (and any closure event you choose).
• Calculate per-case durations and then produce aggregates (average cycle time, percentiles, trends over time, per-project/per-milestone breakdowns, etc.).

Validation

1. Create a new test case <case_id>.
2. Drag it into Doing, wait 1–2 minutes, then drag it into Done (and/or close it).
3. Re-run the API search including cols=events.
4. Confirm you can see:
   • an event for the move into Doing with a timestamp
   • an event for the move into Done and/or the closure event/time
5. Confirm your external calculation matches the elapsed time you observed.

Native option going forward

If cycle time measurement is a recurring requirement, consider using FogBugz Time Tracking going forward so work time is captured natively and reporting does not require parsing event logs.