Tandemu is not a project management framework. It doesn’t tell you how to organize your backlog or run your planning meetings. It works alongside whatever process your team already uses.
But it does change what you need from that process.
What Tandemu replaces
Daily standups (the status-reporting kind)
The standup where each person says “yesterday I worked on X, today I’ll work on Y, no blockers” is redundant when Tandemu captures that information automatically. Running /standup generates a team report from real data — tasks completed, tasks in progress, friction hotspots — without anyone preparing or attending a meeting.
Teams that value the standup as a coordination mechanism (not just status reporting) can keep it. Tandemu just removes the need to manually collect the data.
Timesheets and manual time tracking
Tandemu tracks active development time from Claude Code sessions. The time between starting a task (/morning) and completing it (/finish) is the actual time spent. No rounding to the nearest 15 minutes. No end-of-week time reconstruction.
Velocity estimation ceremonies
Story points exist because teams need to predict how long work will take. But with AI agents, the variance in task duration drops significantly. A task that might take a junior developer 3 days and a senior developer 1 day now takes either of them a few hours — because the AI handles the implementation mechanics.
When tasks consistently complete in hours rather than days, velocity becomes less about estimation and more about throughput: how many tasks does the team finish per week?
How Tandemu complements existing frameworks
With Scrum
| Scrum Ceremony | With Tandemu |
|---|---|
| Sprint Planning | Keep it. Tandemu pulls tasks from your sprint via Jira/Linear/ClickUp. |
| Daily Standup | Replace with /standup or make it async. Data is already captured. |
| Sprint Review | Use Tandemu’s dashboard to show what was delivered, AI ratio, and cycle times. |
| Sprint Retro | Use friction data to identify systemic problems (specific files, patterns). |
Tandemu doesn’t interfere with sprint boundaries. It just removes the manual data collection that makes ceremonies tedious.
With Kanban
| Kanban Principle | With Tandemu |
|---|---|
| Visualize work | Your board stays. Tandemu tracks the same tasks via the API. |
| Limit WIP | Enforced — one active task per developer at a time. |
| Manage flow | Cycle time is measured automatically per task. |
| Make policies explicit | /morning and /finish create clear start/end boundaries. |
Kanban teams benefit the most from Tandemu because the methodology is already flow-based. The single-active-task constraint aligns naturally with WIP limits. Cycle time measurement is automatic.
With no framework
Some teams — especially small ones — don’t use a formal framework. They just have a list of issues and assign them. Tandemu works perfectly here:
- Connect your GitHub Issues or Linear board
- Developers pick tasks with
/morning - Work gets tracked automatically
- Leads see the dashboard
No ceremonies required. The methodology is embedded in the tooling.
What’s genuinely different
Task-level granularity
Traditional frameworks measure at the sprint level (Scrum) or the flow level (Kanban). Tandemu measures at the task level. Every task has:
- A start time (when the developer ran
/morning) - An end time (when they ran
/finish) - Lines changed (total, AI-generated, manual)
- Commits made
- Repos touched
- Duration in minutes
This granularity means you can answer questions like “which types of tasks take the longest?” or “does the AI ratio differ between bug fixes and features?” — questions that sprint-level metrics can’t answer.
AI as a first-class participant
Scrum and Kanban were designed for human teams. They don’t account for a team member that writes code 10x faster, never gets tired, but sometimes hallucinates. Tandemu treats AI as what it is: a tool that the developer directs. The AI ratio metric exists because knowing how much of your codebase was AI-generated is a new, important question that no existing framework addresses.
Friction as a signal
Traditional frameworks detect problems through retrospectives — someone mentions that a particular module was hard to work with. Tandemu detects this automatically through prompt loops. If a developer asks Claude to fix the same file five times, that file has friction. This data surfaces in real time, not two weeks later in a retro.
Zero ceremony overhead
The biggest complaint about Scrum is the overhead: planning, grooming, standup, review, retro. Kanban is lighter but still requires board maintenance and WIP discipline. Tandemu’s overhead is two commands: /morning and /finish. Everything else is automatic.
Migration path
You don’t need to abandon your current process to adopt Tandemu.
Week 1: Install Tandemu, connect your ticket system, have developers start using /morning and /finish. Keep everything else the same.
Week 2: Replace the daily standup with /standup (or make it async). Review the dashboard in your sprint review or team sync.
Week 3: Look at the friction data. Are there files or modules that consistently cause prompt loops? Discuss in retro.
Week 4: Check your team’s cycle times and AI ratios. Are they what you expected? Adjust your process based on real data instead of intuition.
The framework adapts to you, not the other way around.