Agile Metrics Are Useful Only When They Change the Next Decision

When you work on a small product, it is tempting to borrow the metrics language of a large engineering organisation: velocity, utilisation, release count, story points completed.

I have done that too. Then I have had to ask the less comfortable question: what decision would this number change on Monday? If the answer is “none,” the metric is administration rather than management.

At VEAI LAB, I am building care-related products where the important work is often not visible in a sprint chart. In ParkinSync, a paper caregiver log is deliberately checked by a person before it becomes analysis-ready data. In CareReady, the difficult part is not only a checklist UI; it is making a no-login, offline-capable family flow fit alongside a facility-managed template flow. Those are reasons to measure carefully, not reasons to measure more.

This is the practical metric model I use: outcomes, decision quality, and team/service health. It borrows from Agile and flow thinking, but it starts with the work in front of me.

Start with the outcome, then admit what is not measurable yet

Early products are not mature enough to manufacture a confident KPI dashboard. CareReady’s family app is public, but its care outcomes are not yet validated. It would be dishonest to publish a retention number or claim a care outcome before the workflow has been validated with the people who would use it.

The useful questions are smaller:

• Can a family complete the intended task without being forced to create an account?
• Can a facility-specific list be redeemed with a share code and still be available when connectivity is poor?
• Does the return-check flow expose an unreturned item clearly enough to act on?
• Which parts of the workflow need validation with families or facility staff before a broader release?

Those questions lead to observable signals: a successful redeem path, a completed checklist, a failed or abandoned step, feedback from a pilot conversation, or a support question that keeps recurring. They are not vanity metrics. They tell me what to change, what to test next, or what not to promise yet.

For a more established service, I would add adoption, task-success, satisfaction, and service-level trends. For an early-stage service, disciplined uncertainty is a valid result: the right metric can tell you that you do not yet have enough evidence to scale.

Measure the time to trustworthy value, not just the time to code

Lead time is useful when it means more than “ticket opened to ticket closed.” In a care-related data flow, value is not delivered when an OCR function returns a string. It is delivered when the data is safe enough to be reviewed, understood, and used for its intended analysis.

ParkinSync makes that distinction concrete. The pipeline uses Textract to help extract structured paper-log data and enriches it with weather and indoor-temperature context. But the repository explicitly keeps a human verification step before cloud ingestion. That adds a step. It also prevents a plausible-looking OCR error from quietly becoming a row in a dataset.

So the operational question is not simply, “How do I remove the human from the loop?” It is:

Where does human review reduce enough downstream risk to be worth the time it takes?

That is a better lead-time conversation. It lets a team improve scanning instructions, form design, validation checks, or exception handling without optimising away the control that makes the result trustworthy.

Strategy alignment should be visible in the trade-offs

Metrics can reveal whether a project is drifting from its purpose. In this lab, the purpose is not to create the largest possible feature list. It is to reduce a small, real burden in everyday care while keeping the system explainable and maintainable.

That is why CareReady uses a six-character share code for a family to retrieve a facility template, rather than requiring a family account before the first checklist can be used. It is why the checklist persists locally with IndexedDB. It is why the staff administration path has authentication, while the public redeem path has narrow validation limits. These are product, security, and service decisions together.

The strategic measure is therefore not “how many features shipped.” It is whether the work keeps making the intended path simpler without moving unmanaged risk somewhere else. A feature that adds friction for a family, creates unclear staff ownership, or makes support impossible is not automatically progress because it was completed inside a sprint.

Watch service health while delivery is moving

Fast delivery becomes fragile when the team treats release and support as someone else’s future problem. The signals I want close to a release are deliberately ordinary:

• Can the build and deployment path be reproduced?
• Do automated checks exercise the behaviour the live handler actually uses?
• Is there a rollback or correction path?
• Are credentials, personal data, and source documents handled appropriately?
• Does a failure produce an understandable next action rather than a mystery?

I learned this the unglamorous way on ParkinSync. The test suite had drifted from the real Lambda handler: it imported a module that no longer existed and asserted an outdated return shape. The deployment packaging also needed correction so the configured handler and shipped code aligned. Neither issue looks impressive on a roadmap. Fixing them made the system more honest: the checks now speak about the code that actually runs, and the deployment path matches the implementation.

That is a health metric in practice. Not a number to reward or punish someone with, but evidence that the delivery system can be trusted a little more than it could yesterday.

Use numbers as invitations to investigate

Agile metrics become harmful when they are turned into individual quotas. A rising cycle time can mean a bottleneck, a hard problem, a missing decision, or a necessary safety review. A lower defect count can mean better quality — or less reporting. Numbers need context before they deserve a conclusion.

My working rule is simple: every metric must have an owner, a decision it can influence, and a conversation attached to it. If it cannot answer “what should we learn or change next?”, I remove it from the dashboard.

That is the kind of delivery practice I bring to client work as well: small evidence loops, visible trade-offs, and no pretending that a neat chart is the same thing as progress. The underlying systems are public where they can be: ParkinSync and CareReady. More about VEAI LAB’s work is at hire-veai.com.