<aside> 💡
This is a starting point, not a contract. Adapt it to what the work needs.
</aside>
Every other document in this framework is about how the team works. This one asks whether it's working. The metrics here aren't numbers to report upward. They're signals for the team. A way to notice when something in the process is creating friction and decide whether to adjust.
Two types of signals are useful: formal metrics you track over time, and gut checks you return to periodically. Both matter.
Track these over time. They don't need a dashboard. A simple log updated after each sprint or handoff is enough.
| Metric | What to measure | Target |
|---|---|---|
| Handoff revision rate | How often does work come back for major revision after handoff? | Trending down over time |
| Post-handoff questions | How many design questions come back from developers during build? | Fewer than 3 per feature |
| Onboarding time | How long before a new team member is contributing independently? | Shorter than the previous hire |
| Review cycle length | How many rounds of review does a typical feature require before handoff? | Trending toward one or two |
A note on targets: these are starting points. Set your own based on where the team is now. The goal is directional improvement, not hitting an arbitrary number.
Run these informally once a month or after a project wraps. No spreadsheet needed. Just honest answers.
If the answer to the last question is overhead, something needs to change. The framework exists to reduce friction, not add it.