Ask Your Dev Team how they measure success
Velocity and story points aren't what matter. Learn how to evaluate whether your developer measures success the way you do: on time and on budget.
Ask your developer how they measure success and pay close attention to the answer.
If they start talking about velocity, story points, or sprint burndown charts, you should be skeptical. Those are internal metrics. They measure activity, not outcomes. And as someone paying for a result, you care about outcomes.
Success means delivery
For a work-for-hire engagement, success is straightforward: did they deliver what they promised, on time and on budget?
That’s it. Everything else is a supporting detail.
A good developer should be able to articulate exactly how they keep projects on track toward those two goals. That includes how they plan, how they estimate, how they communicate when things shift, and how they course-correct when a deadline or budget is at risk.
If they can’t explain that clearly, they’re either not tracking it or they don’t want to talk about it. Neither is great.
Output is the wrong metric
Some developers will tell you about the volume of work their team produces. How many tickets they close per sprint. How many story points they burn through. How fast they move.
That’s not your metric. That’s theirs.
Output measures how busy a team is, not how effective they are. A team can close 50 tickets in a sprint and still miss the deadline. They can burn through story points at record speed and still blow the budget.
Any developer focused on output as an external-facing metric for clients is looking at the wrong things. They’re measuring effort, not results. And you’re not paying for effort.
What to ask
- “How do you define project success?” Listen for delivery, timelines, and budget. If the answer is vague or internally focused, press further.
- “How do you track progress against milestones?” You want to hear about clear deliverables, regular check-ins, and honest reporting. Not dashboards full of charts you don’t understand.
- “What happens when a project is at risk of going over time or budget?” This is the real question. Every project hits bumps. What matters is how early they flag it and what they do about it.
- “How do you evaluate your own performance?” A developer who can self-assess honestly is one you can trust to be honest with you.
Commitments, not activity
The best developers measure themselves by their commitments. They tell you what they’ll deliver and when, and then they do it. When something changes, they tell you early, explain why, and propose a path forward.
That’s the kind of accountability you should expect. Not a dashboard. Not a velocity chart. A developer who delivers on their word.
Expect better. Build better.