An important lessons I’ve learned as a developer and a leader is this: the value of your work is only as good as your ability to communicate it.

This past month I was involved in a few conversations around improving our “Sprint Reviews” and how to make them better. The first was with one of my developer’s who said, “What I love about frontend work is that it’s always visible - you can show what you’ve been working on. I don’t envy our backend developers. They always find it hard to explain what exactly they’ve been doing.”

The second conversation was with my boss, discussing the real purpose of sprint reviews. “The company paid for two weeks of development time,” he said. “The sprint review is where we show stakeholders what we built.” This delved into a conversation around how do backend developers, or our core blockchain developers explain their work.

This got me thinking about storytelling, and how do make invisible work visible to non-technical people?

The Frontend Developer’s Advantage (And Why It’s Not Enough)

Frontend developers have it easy during sprint reviews. They can pull up a screen, click a button, and say “Look, I built this thing that users can interact with.” The value is usually obvious.

But here’s what I’ve learned after years of watching developers present their work: even frontend developers often miss opportunities to tell compelling stories. They show the what but skip the why and the who.

The best developers - regardless of whether they work on frontend, backend, or infrastructure - understand that their job isn’t just to build things. It’s to build things that create value for real people. And in sprint reviews, your job is to connect the dots for the stakeholders between the code and its value.

The Art of Finding the Story

The key insight here is that every piece of code you write serves someone, even if they never see the code itself. Your job as a storyteller is to trace that path from your keyboard to the end user’s experience.

When preparing for your next sprint review, ask yourself:

  • Who benefits from this work? (Users, other developers, support team, sales team?)
  • What problem does this solve? (Current pain point or future opportunity?)
  • What becomes possible now that wasn’t possible before? (New features, faster development, reduced risk?)

Sometimes the beneficiary is obvious - like building a user-facing feature. But often, you need to think through the chain of impact. Your database optimization might not directly help users, but it enables the application to handle more traffic, which means better performance during peak times, which means happier users and more revenue.

Let’s go through a few examples.

Example 1: The API That Nobody Sees

Let’s say you built an API that connects to the blockchain and exposes data in a JSON format. Here’s how most developers would present it:

“I built an API endpoint that queries the blockchain and returns transaction data in JSON format. It handles authentication and rate limiting.”

That’s technically accurate, but it’s dead on arrival with non-technical stakeholders. Here’s the same work through the storytelling framework:

“You know how our customer support team has been getting complaints about users not being able to see their transaction history? Well, I built the foundation that will solve that problem. I created an API that pulls transaction data from the blockchain and formats it so our frontend team can display it clearly to users. But here’s the cool part, this doesn’t just solve the customer support issue. Marketing can now use this same data to create dashboards showing user engagement, and our business development team can use it to demonstrate our platform’s activity to potential partners.”

Same work. Different story, and completely different impact to the stakeholders.

Example 2: The Refactor That Seems Pointless

Code refactoring is perhaps the hardest thing to justify to stakeholders. Here’s the typical approach:

“I refactored the payment processing module to improve code readability and reduce technical debt. It will help in the future.”

That might as well be speaking ancient Greek to most stakeholders. Here’s how to reframe it:

“Remember last month when we wanted to add support for the new stablecoin, but it took three weeks instead of three days? That happened because our payment code was tangled up and hard to modify. This sprint, I untangled that code and restructured it so that adding new payment methods becomes straightforward. The next time we want to support a new token or integrate with a new payment provider, we’re talking days instead of weeks. That means we can respond to market opportunities faster and take on client requests that we previously had to turn down.”

Now you’re speaking their language.

When the Story Isn’t Obvious

Of course, there are times when the connection to user value is genuinely distant. Maybe you spent the sprint fixing a subtle bug that only occurs in edge cases, or implementing a dependabot security update that users will never notice.

In these cases, be honest about the nature of the work, but frame it in terms of risk and maintenance:

“This sprint, I focused on the kind of work that’s invisible when done right, but catastrophic when ignored. I fixed a bug that only affects users in a specific timezone during daylight saving transitions. It sounds minor, but it would have caused transaction failures for 15% of our user base twice a year. I also updated our authentication system to address a security vulnerability. Users won’t notice the change, but it protects both them and us from potential breaches.”

The Two Purposes of Sprint Reviews

My boss was right about sprint reviews serving two purposes: creating pride in our work and demonstrating value to the organization. But what I’ve learned is that these purposes are connected.

When you can articulate the value of your work clearly, you feel more pride in it. And when stakeholders understand the impact of what you’re building, they’re more likely to support your future work and recognize your contributions.

The developers who struggle with sprint reviews often think their job is just to write code. The developers who excel understand that their job is to build things that matter, and then help others understand why they matter.

Your Next Sprint Review

Before your next sprint demo, take fifteen minutes to think through your stories. For each piece of work you completed, trace the path from your code to human impact. Find the personas who benefit from your work, even if they’re internal users or future developers.

Remember: the goal isn’t to oversell or exaggerate the importance of your work. It’s to help others see the connections that are obvious to you but invisible to them.

The growth happens when you can make the invisible visible. You know that your code has an impac, now it’s your job is to tell that story.