I've been doing agile coaching and engineering management for long enough to know that most teams measure the wrong things. Or, more commonly, they measure nothing at all and just vibes-check their way through sprint planning. "How's the sprint going?" "Fine." "Are we on track?" "I think so." Cool. That's not data. That's horoscopes.
The tools I'm about to walk through exist because I kept building the same spreadsheets over and over for different teams. WIP aging charts in Google Sheets. Capability matrices in Notion that nobody updated. Capacity plans in Excel that broke every time someone went on vacation. At some point I snapped and just built them properly — browser-based, no accounts, no servers, data stays on your machine.
Here are six agile tools I shipped this week, what problems they solve, and why I think you might actually use them.
Your WIP is lying to you
Every kanban board shows you how many items are in progress. Three items in dev, two in review, one in testing. Great. But that number is almost useless by itself.
What matters isn't how many items are in progress — it's how long they've been there. A column with three items where each one arrived yesterday is fine. A column with three items where one has been sitting there for 22 days is a disaster hiding in plain sight.
This is the core insight behind WIP aging, and it comes directly from Little's Law: average cycle time equals work in progress divided by throughput. If your WIP includes ancient items, your average cycle time is being dragged up and your flow metrics are lying to you. ActionableAgile made this concept popular in the kanban world, and it's genuinely one of the most underrated agile metrics out there.
The WIP Age Chart I built lets you visualize this instantly. Drop in your items, their start dates, and their current column — you get a scatter plot showing age by stage with configurable thresholds. Items aging past your 85th percentile cycle time get flagged red. No more "oh I didn't realize that ticket had been in code review for three weeks."
Six dimensions, one radar
Here's a question that should be easy but never is: "Is the team healthy?"
Not "are they delivering stuff" — that's one dimension. I mean the full picture. Are they delivering the right stuff? Is their flow smooth or choppy? Can they make commitments and keep them? Is quality holding up or are they shipping fast and breaking things?
Inspired by Daniel Vacanti's work on kanban flow metrics, I built a Six Dimensions Radar that scores teams across six axes: Quality, Responsiveness, Predictability, Productivity, Flow, and Value. You input your metrics, it renders a radar chart, and suddenly you can see that your team is crushing it on productivity but their predictability is garbage. That's a conversation starter. That's the kind of team performance visibility that turns a retrospective from "what went well / what didn't" into something with actual teeth.
The bus factor spreadsheet nobody maintains
Every engineering org I've worked with has had some version of a skills matrix. Usually it's a Google Sheet that someone created during an offsite, got populated once with enthusiasm, and has been slowly rotting ever since. Meanwhile, the actual bus factor keeps getting worse and nobody notices until Sarah goes on maternity leave and suddenly nobody knows how the payment gateway works.
T-shaped skills sound great in theory. In practice, nobody tracks them. The Capability Gap Analyzer makes it trivially easy: list your team members, list your capabilities, rate proficiency on a simple scale, and it immediately shows you where the gaps are. Single points of failure light up. Skills that only one person has get flagged. You can export the whole thing as JSON and actually keep it updated because it takes thirty seconds instead of an afternoon.
Stop forming teams by accident
Most teams aren't designed. They're accidents. Someone gets hired, they join whichever team has capacity, and three months later you have a team of four backend engineers and zero frontend people trying to deliver a user-facing feature. Conway's Law predicts exactly what happens next: the architecture mirrors the team structure, and you end up with a beautiful API that nobody can actually use because the UI is an afterthought.
Team Topologies by Matthew Skelton and Manuel Pais made a compelling case that team design is system design. I agree completely. The Team Formation Optimizer takes your people, their skills, and your constraints (who works well together, who needs mentoring, what capabilities each team needs) and helps you explore formations that actually make sense. It won't replace human judgment — nothing should — but it surfaces combinations you wouldn't have thought of and highlights obvious imbalances before they bite you.
"How much work is coming?" is a forecasting problem
Sprint planning usually focuses on what's already in the backlog. But the backlog isn't static. New items arrive constantly — bugs, feature requests, tech debt, that thing the CEO saw at a conference and now considers urgent. If you don't model the arrival rate, your capacity planning is fiction.
This is a classic time series decomposition problem. The Backlog Arrival Rate Forecaster uses multiplicative seasonal decomposition to break your historical backlog arrivals into trend, seasonal, and residual components. Feed it six months of data and it'll tell you that yes, backlog arrivals spike 40% every January (post-holiday feature requests) and drop 25% in August (everyone's on vacation). The approach follows the same principles outlined in Hyndman & Athanasopoulos's forecasting textbook — not because I'm trying to be academic, but because the methods work and they're well-understood.
Knowing your delivery forecasting numbers means nothing if you don't also know what's coming in. Inflow matters as much as throughput.
Capacity planning that accounts for reality
The most common capacity planning I see is: "We have 5 devs × 10 points each = 50 points per sprint." This is wrong in so many ways I don't even know where to start. People take vacation. People get sick. People get pulled into incidents. New hires ramp up slowly. Seasonal factors affect availability — good luck staffing a full team between Christmas and New Year's.
The Seasonal Capacity Planner accounts for all of this. You input your team composition, planned absences, hiring timeline, and seasonal adjustment factors. It produces a realistic capacity forecast that doesn't pretend everyone is available 100% of the time. This is basically the Theory of Constraints applied to team capacity — your actual throughput is determined by your bottleneck, not your theoretical maximum. Sprint planning with realistic capacity numbers is a different experience entirely.
All of this runs in your browser
I'm going to keep hammering this point because it matters: none of these free agile tools send your data anywhere. No servers. No accounts. No analytics tracking your team's performance data. Everything runs client-side in JavaScript. Your data lives in localStorage. You can export and import JSON files to move data between machines or share configurations with teammates.
Most of the tools also support URL state — meaning you can configure a view and share the URL directly. Someone clicks it and sees exactly what you see. No login required.
These are browser-based tools built for people who want to understand their teams better without handing their data to yet another SaaS vendor. If you're doing kanban flow analysis or trying to improve your agile metrics visibility, I think they'll save you time.
I ship tools weekly. If there's something missing or broken, open an issue or just tell me on Twitter. I read everything.