My Sprint Velocity Was Perfect - My Data Portfolio Never Shrank

I dedicated nearly fifteen years to data teams, starting as an engineer, then an analyst, progressing to a product role and senior executive position, and eventually becoming the go-to person when other data leaders faced board skepticism. Throughout my career across various companies, a recurring pattern persisted, and it took me years to recognize and articulate it clearly. The sprint board always appeared impressive. Tickets were completed on time, the velocity chart showed consistent upward progress, and each retro was marked as "good sprint, ship it." Meanwhile, the data portfolio, comprising dashboards, pipelines, models, and reports that the team managed, continually expanded. It never diminished, not once over the years, at any company I have worked for or advised. That's not a coincidence. It's the direct, predictable result of measuring the wrong thing. Closing a ticket is a motion. It is not a decision. In many data teams' cultures, "done" often implicitly means "valuable." A ticket gets closed, the burndown chart decreases, and the team quickly moves on. No one usually pauses to consider if what was delivered is still worth the compute resources, maintenance hours, or potential on-call issues six months down the line, since that question was never formally assigned or considered. I uncovered dashboards that hadn't been interacted with in over a year but continued to refresh every night. They even prompted alerts at 2 AM when upstream schemas changed, and someone spent time fixing them. These dashboards weren't created with bad intent; they were built to answer genuine questions three reorganizations ago, and they've been running nonstop since then. When you consider this across every team and over multiple quarters, it results in a portfolio driven mostly by inertia, largely unseen by most. Most engineering orgs already know how to talk about this everywhere except here. APIs get deprecated with a notice period. Feature flags get sunset on a schedule. There are entire job titles built around retiring code responsibly. Somehow, none of that discipline made it to the data layer. A team will spend a whole sprint carefully deprecating an internal API with a six-week warning, then let a dashboard nobody's opened since last year run in production indefinitely, because deleting it isn't anyone's job. Building it was. Killing it never was. The velocity chart can't see this, by design. This is the part that took me the longest to understand: it's not that engineering leadership doesn't care. It's that the standard metrics simply cannot capture the real problem. Velocity measures throughput, and sprint completion shows if tasks are finished as planned. But neither metric indicates if the entire portfolio has become leaner, more focused, or more valuable. They only show if more has been added. According to Gartner, about 85% of big data projects fail to deliver the expected value, meaning most data initiatives don’t pay off. This figure specifically highlights that the project didn't generate the expected benefits; it doesn't reveal what happens afterward. In my experience, most often nothing happens: projects continue to run with little use because there’s no one responsible for shutting them down, and no incentive in the velocity metrics to do so. A project doesn't need to succeed permanently; it just needs to avoid any review or assessment. The discipline you already run everywhere else You are already applying this logic consistently across the business, without needing clarification. When a product line stalls, you don't indefinitely add more teams; instead, you address the actual issues or withdraw investment to focus on more promising areas. Unused features are removed from the roadmap, not kept out of politeness. If a regional expansion fails, there's a straightforward discussion about whether to continue funding it, rather than increasing the budget for more of the same. This mindset about capital allocation is second nature to you, as you wouldn't accept anything less in other parts of the company. Now, look at what actually happens when the data team's numbers disappoint you for the third year in a row. The fix is never "let's look at what we're already carrying and decide what to stop." It's "let's migrate the warehouse." "Let's add more sources." "Let's hire two more engineers." "Let's buy a new tool." Every single response is a built response. Not one of them is the stop-and-decide response you'd reach for instantly, without thinking twice, in every other part of the company you run. This is the part that should truly concern you. It's not a technology or talent gap; even if you add a better tech stack and smarter engineers, you'll likely face the same disappointing results again in eighteen months. The key issue wasn't technical but related to decision-making discipline, which already exists but was never applied in this context. No one in management specifically requested or enforced this discipline here. The reason isn't because data behaves differently from other resources you allocate capital to, but because no one thought to apply the same rules that govern every other dollar in the business. Where my own advice fell short. I've personally made this exact mistake in print, not just observed others doing it. In an earlier article on this site , I advised CEOs to address this issue using a KPI ownership matrix, quarterly data audits, and stricter tracking of Data ROI and Data Utilization. While all these suggestions are still generally correct, they were insufficient on their own. It was only after witnessing someone implement these strategies that I understood why. I described a retail chain conducting similar audits and discovering that 60% of its data hadn't been accessed in over a year, a concrete, meaningful figure that makes for a compelling slide. However, structurally, nothing changed because an audit that reveals a number isn't the same as a system that mandates action. Data ROI and Utilization indicate waste, but they don't grant anyone the authority, the scheduled time, or the obligation to address the issues. The gap lies between identifying a problem clearly and creating a system to fix it, something I hadn't fully recognized at the time. I went further with that admission a year later, in more depth, and it turned out to be worse than "not enough." I'd been teaching utilization and ROI as the two anchor numbers for a data operation, and both were wrong, not just incomplete. Utilization measures activity, not value; it can climb because people are touching data more often, with no guarantee that any of that touching is changing a single decision anyone makes. ROI is a legitimate number, but it's a lagging one: by the time it moves, whatever caused it happened months earlier, which makes it close to useless for steering anything in the present. What actually replaced them was a pair of numbers closer to the retirement question this piece is about: is the hidden workaround time the business is quietly absorbing because of bad data products actually going down, quarter over quarter, and does the team still have real room to build, or is it spending down its own capacity just to stay upright? Neither one is about how busy anyone looks. Both are about whether the portfolio is getting healthier or just bigger. What the inventory actually looked like Nothing here requires new tools; most teams already possess the data needed for retirement decisions; no one has compiled it in one place and posed the question. The only organization I observed to break this pattern started with a very simple spreadsheet: every dashboard, pipeline, and report was evaluated against three criteria. The first was the last time it was used, tracked directly from the BI tool's access logs or query history, not based on opinions in meetings. The second was the monthly maintenance cost, covering compute, storage, and an honest estimate of maintenance and on-call hours, similar to what you'd provide to a stakeholder requesting a new build. The third was the number of people who would notice if it disappeared for a month, confirmed by asking actual users, rather than estimating from an org chart. Or if you love chaos as I do, just shout it down and see what happens. Anything that scored badly on two of those three columns became a retirement candidate automatically. No debate required to get on the list. The debate was deliberately reserved for what happened next, not for whether something qualified. Separating "is this a candidate" from "what do we do about it" was the single change that kept the list from turning into a political argument every time someone tried to build it. What Made it Sick The change was less significant than it appears: retirement candidates underwent quarterly planning columns just like new roadmap items, the same meetings, stakeholders, and effort estimates based on story points, competing for the same engineering hours as new features. Each retirement had its own definition of done, mirroring a feature's: the pipeline was halted, the dashboard archived instead of deleted (to avoid panic if someone needed it later), the on-call rule was removed, and a single line was added to the team wiki explaining what it was and why it was retired. The key rule that kept it in use, beyond inventory or meeting frequency, was that if a stakeholder objected, saying "we still need this," it didn't mean they had veto power. Instead, it appointed them as the accountable owners of that item's ongoing costs, with the details documented in a visible tracker accessible to everyone. This one mechanic was more effective than all the others combined, transforming a casual "just in case" opinion into an official decision linked to a real cost. It took two quarters before any of this stopped feeling artificial. By the third, half the team had stopped waiting to be asked and started nominating retirement candidates on their own, because saying "I don't think anyone needs this anymore" had finally become a normal sentence in that room, backed by a log file instead of a hunch. This excerpt highlights that retirement decisions are just part of a larger issue: defining what makes a data investment healthy, beyond just identifying cuts. Since that first discussion, I've been working to understand this more deeply. The solution isn't just about improving audits; it's about developing a dependable metric to assess the cost of a data team compared to its tangible results, and identifying when a portfolio no longer provides value for money. Try it on your own team this quarter. Not as an experiment to prove a point, as an actual planning-session agenda item: before the next roadmap gets approved, name one thing that should be retired and put it through the same review. Watch how unfamiliar that sentence feels the first time, and how fast that changes. Lior Barak has spent fifteen years building, breaking, and rebuilding data functions across European startups, scale-ups, and mid-sized enterprises, including Zalando and idealo. He turned this exact pattern into the spine of a business fable, What Data Really Costs . The first two chapters are free to read.