Some Scrum Teams track velocity. Others obsess over story points or cycle time. Others thoughtfully measure various value metrics.
I once worked on a team that had one metric front and center on our team room's whiteboard: Days Since Last Release
Our goal? Keep it at zero.
The Most Honest Metric in the Room
Unlike velocity or throughput, “Days Since Last Release” doesn’t lie. If your number is climbing, it's telling you something important: your value isn't flowing into production.
That number forces conversations:
Why haven’t we released?
What is stopping us?
Are we really done?
Is our Definition of Done enough?
If you're organization is still on a monthly, or worse quarterly, release schedule, what is your Scrum Master doing about it?
Release Frequency Matters, Too
Scrum is about delivering valuable, usable increments every Sprint. That means release readiness should never be theoretical. If you're not releasing, you're just building up inventory. And you can't realize value without delivering.
Release frequency is another direct signal of agility. It reveals how close your team is to delivering real value. The longer the delay, the greater the risk:
Risk of stale feedback
Risk of building the wrong thing
Risk of growing technical debt
Risk of detachment from your users
What It Takes to Release Frequently
Tracking this metric works best when your team has:
A Clear and Practical Definition of Done
Releasing frequently starts with agreeing on what “done” means, and making sure that includes releasability.Product Owner Willing to Prioritize Value Over Volume
Frequent releases depend on delivering small slices of value, not bundles of features.A Culture That Embraces Iteration Over Perfection
Perfectionism delays delivery. Frequent release teams ship, learn, and refine.Automated Testing and Continuous Integration
Manual testing slows teams down. Automation ensures that increments are safe to release without delay.Feature Flags and Toggle Strategies
These techniques allow you to release code without exposing it to users until it's ready—decoupling delivery from launch.Streamlined Deployment Pipeline
A repeatable, fast, and secure deployment process is essential. If releasing is painful, you won’t do it often.Cross-Functional Team Capabilities
Teams should have everything they need, UX from design to QA to DevOps, in order to move from idea to production without waiting on external groups.Minimal Bureaucracy
If every release needs five approvals and a change request form, your agility is being blocked by process debt.Real-Time Monitoring and Alerting
Confidence in your ability to observe, detect, and respond to issues in production is critical for sustainable frequent releases.Stakeholder Support for Incremental Delivery
Product, legal, marketing, and compliance all need to buy into the idea that value doesn’t have to be bundled to be useful.
Even if you don't release to production every day, your product should be ready every day. That’s the real point.
But What If We're Releasing the Wrong Thing Quickly?
Some might ask, “What’s the point of releasing frequently if we’re just releasing the wrong thing?”
That’s a fair question. But here’s the truth: You’re far more likely to discover you’re building the wrong thing if you release it.
Frequent releases are not the goal in isolation. They are the mechanism for learning, for closing the feedback loop, and for making evidence-based decisions.
If you're releasing the wrong thing slowly, you're simply wasting time in larger batches. If you're releasing the wrong thing quickly, you get the chance to course-correct fast.
Release frequency doesn’t solve poor Product Ownership, lack of customer insight, or unclear value. But it exposes those problems sooner, while there’s still time to fix them.
How to Start
Post a big sign that says “Days Since Last Release” in your workspace or digital board.
Reset it to zero when you release.
Let it climb when you don’t.
Let it bother you.
Let it trigger your next conversation in the Sprint Retrospective.
📊 What Does DORA Say About Release Frequency?
The DevOps Research and Assessment (DORA) team defines Deployment Frequency as:
How often an organization successfully releases to production.
It’s one of the four key DORA metrics used to measure software delivery performance, and it aligns closely with the core goal of agility: delivering value quickly and reliably.
If you're aiming to be an elite team, your “Days Since Last Release” should regularly reset to zero.
⏱️ How Is This Metric Different From Release Frequency?
Both Release Frequency and Days Since Last Release measure delivery, but from different angles.
Think of Release Frequency like your average pace over a marathon. Days Since Last Release is your current speed right now.
Both matter. But only one stares you in the face each day.
Final Thought
If you're using Scrum but haven't released anything in weeks, it might be worth considering: what are we truly aiming to achieve? Scrum isn't about finishing work. It's about delivering it.
So if you say you're Agile, show me your release frequency.