Days to First Value

My second conversation with an agile sponsor is inevitably… metrics. I stopped feeling surprised after a half dozen engagements.  To me the metrics were obvious. Constant, fast delivery makes it easy to track your customers happiness and buying decisions.  Constant feedback loops help people make better business decisions faster. I witnessed this for years. My observational evidence though is an act of faith for new agile organizations. They need their own evidence. Evidence is powerful. Measurements and trends are powerful, and most organizations want to track what is important to them.

Days to First Value

Over time I’ve helped people develop several metrics that work for them. Days to First Value, passed on to me by my colleague Steve Fastabend through his work at Northwestern Mutual, has proved invaluable.  It works. It works at multiple levels of an organization and for multiple purposes. Did you get enough emphasis on the ‘multiple’?  As Alton Brown says No Unitaskers.

How it works

  1. Choose something to consistently track. A piece of work like a product backlog item, feature, epic, project, defect, customer service call….anything.
  2. Decide on a trigger.
  3. Decide when you get your first value from it.
  4. Measure the time between with a goal to reduce it

Examples at Multiple Levels

  • Business Question: How effective is our live customer service?

    A customer call center decides to track incoming support calls from [Pickup] to [Completed Transaction]. This helps them measure how quickly they get a curious or blocked customer to a transaction of value, whether on the phone or redirected online. Measure days, hours or minutes to first value.

  • Business Question: How quickly does our team produce value?

    A Scrum team decides to track features from [Acceptance at Sprint Planning] to [Confirmed earliest use of that feature in production].  This helps measure their value-sense; decomposing the feature for early value, producing enough for the Product Owner to release and their customers to want to use, and the quality and release practices that allow quick delivery.

  • Business Question: How quickly are we getting a return on investment?

    A portfolio management team decides to track Epics from [Funded] to [Confirmed earliest use in production]. This helps them use Throughput Accounting measurements and watch how efficiently the system uses money.


  • Make clear definitions of Ready for the Trigger and Done for first value
  • Capture it for every piece of work. I’ve seen teams use stickers, marks, and built-in timers. the methods are endless.
  • Make this a constant measure. Its easier to track and attribute changes in Days to First Value if its measured all the time.


I hope this was helpful.  If you have questions, or want to talk more about implementing this metric in your organization please call or email. 281-520-8750 . I enjoy talking about metrics.

As always, I am curious about your experience.  Please share. Do you use this metric today? Do you apply it differently? Do you use a metric like this one?  How do you use the data?



The Titan of Transparency – your superhero Scrum Master

I have seen a lot of Scrum Masters with capes.  Well a lot of Scrum Master Cartoons with capes…and wizard robes. It’s inspiring and I know, I Know that Scrum Masters are super heroes.  What I don’t know is their super power. I know a good Scrum Master ‘when I meet one’ but that intangible quality has been a frustrating mystery to me over the years. When I made the shift into training and coaching I spent hours poring over the core materials that make up Scrum and other agile frameworks to understand them down to their bones.  And that’s when I found it. In the Scrum Guide, plain and clear.  The Scrum Master’s super power is transparency. They are the Titan of Transparency.  It was so clear I saw right through it.

One Question – Enormous Tracts of Transparency

The Scrum Master gets to ask and judge one question, ‘Are we doing Scrum?’.  It’s a common trap to think of it as a small one. Scrum is based on the pillars of Inspection, Adaptation and Transparency, a large field for that one question! It is also a proactive question.  While a newer team may need a Scrum Master’s focus on the basic of ceremonies, roles and artifacts, a reactive approach, an effective Scrum Master soon graduates to a proactive enabler, asking the questions ‘Are we doing Scrum?’ everywhere the work gets done. The Scrum Masters with ‘it’, that superhero gleam, are creating, promoting and preserving transparency across the process, artifacts, and culture.  Let’s explore some specific ways Scrum Masters champion transparency in the realm of Scrum Artifacts.

Artifact Transparency  

The Scrum Guide prescribes a few artifacts of note, the Product Backlog, the Sprint Backlog and the Increment (the working software). The Scrum Guide states

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. … To the extent that if the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.”

Seems obvious enough…but we lose that focus in the day to day sprint toward our goal. The Scrum Master, Titan of Transparency, ensures that each of those artifacts, as well as any other artifacts the organization values in their Scrum process, are transparent.  Transparency really includes everything that makes the artifact useful in making decisions.  

  • Availability Can everyone who makes decisions find and access the Product Backlog, Sprint Backlog and Increment?
  • Usability Is the artifact in a fit for purpose format?  Is it too complicated? Is it detailed enough?
  • Accuracy Is the artifact correct?  Are we showing an Increment that meets the definition of Done? Do decision makers know that definition? Is the Product Backlog up to date?
  • Understandability Does the artifact communicate clearly and concisely?  

Scrum Masters don’t wait to be told that artifacts aren’t working. The Scrum Guide explicitly lays out the sleuthing expectations:

A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.”

Titans of Transparency notice things.  They notice when feedback increases, or decreases.  They notice who tends to be confused by the backlog, or, the commons patterns of how the team struggles in Product Backlog refinement sessions.  Innovative Titans (the ones with the capes) have even gone so far as meeting with Stakeholders one on one to ask probing questions when Sprint Reviews bring out gaps in the Increment versus stakeholder expectations.  They dig into The Product Backlog, and even the Increment itself to find out where things got cloudy and how they can be improved.

Act with Purpose – Get a Cape

The Scrum Guide is explicit in its expectations of Scrum Master service – to the team, the Product Owner and the Organization.  If you haven’t considered attaining the superpower of transparency, the Scrum Artifacts are a concrete place to start. Another thing to try is mapping the three regions of your Scrum Master domain – process, culture and artifacts – onto a whiteboard and adding shading where you see things becoming less transparent, or noting patterns as they appear.  A transparency map can help you track and activate!

However you decide to grow into your Titan of Transparency cape, the key is to act. Act with the purpose of increasing transparency in every place work is done. I doubt you will run out of places to look.


So you’ve got the green light to build an agile team. Congratulations! Building an agile team is an adventure for everyone involved.

This post is intended to provide steps you can take in order to build a self-organized agile team while also accelerating the value of self-organized, cross-functional teams from the moment they become a team.

Why is this important?

Cross-functional teams deliver working software within one team and one sprint, every sprint.  Self-organizing teams increase quality and reduce risk by owning responsibility for maintainable, sustainable and fit for purpose software.

Valuable working software, every sprint, shouts of a self-organized and cross-functional team. Continue reading

Do You Believe in Magic?

Change is hard. Everyone knows that. Even the people who love change can admit that it is hard.

We’re hard wired to rely on habits, stereotypes and assumptions to free our minds up for new problems. If you need a living example, try moving the coffee from one cupboard to another without telling anyone. See what happens.

This is why many people struggle with a complete transformation of how they work, but when it all comes together, it is simply magic to me. As an agile transformation coach, I know how it is done, yet it is still magic.

So, I recently observed some of this magic between my colleague Konrad and a new Scrum team. The team had a problem and didn’t know how to solve it. Continue reading

Get Decked – Supporting Agile Transformation in Your Definition of Success

babeAs agile methodologies take root and grow in organizations we see trends.  One community corroborated trend is that organizations reduce friction during adoption if their slide decks reflect agile success measures. Quarterly review, annual budget review, annual business strategy, vision summits, all of these types of gatherings have something in common, they reflect on the measures of company success and use them to determine how the company handles money, resources, and vision.  If you are pursuing agile adoption or transformation in your organization, it’s worth the time to think about your definition of success and how agile it is.

Continue reading

The Audit Path – Staying Agile within an SDLC

In an ideal Agile environment you are a small, quick organization full of smart people who are experts in their field.  This is an uncommon ideal. The more common scenario is a large or well established business that sees agile as a way to become more relevant to their customers.  These organizations come pre-packaged with processes and procedures around software development, security, and privacy.  In short they already have an SDLC (software development life cycle).

Continue reading

Documentation – What does it mean?

“Working Software over comprehensive documentation” The Agile Manifesto

Lately my team has struggled with the agile principle of minimal documentation. They have adopted the attitude, see the sense of it, and have gleefully thrown off the expectation that they should be doing any documentation that does not contribute to working software.

But we need it…

Continue reading

The Scrum Master Daily

Like most Scrum Masters my work is self- propelled. Other than ceremonies, minimal documentation and the few backlog admin tasks much of my work is preventative and proactive.  That means discipline.  Discipline, at least for me, is in the form of my Scrum Master Daily, a checklist that walks me through the priorities for my current project and team. Its my daily guidepost on how to navigate what my team needs.  Put simply, its a checklist that fits the needs of the current team for the current project. Continue reading

User Stories – Making the sacred cow useful for your team

User Stories are an artifact of SCRUM, a common but not ubiquitous methodology built on Agile Principles.  As a Scrum Master and Agile coach, I guide the team on User Story creation and adherence to the Agile Manifesto and Principles.  I’ve found in a few projects that User Stories can sometimes get in the way of the work, violating Principle Ten,

Simplicity, the art of maximizing the work Not done is essential.

Continue reading

Iteration 1 – Welcome to My Blog

Here we go.
In faith I’m taking the leap with no pictures, no bio and no links to other work.  Iteration 1.
I took on Agile as a tool and a set of certifications. Little did I know that the methodology simply strengthened my own views on managing people and teams.  Its tenants and ceremonies serve to bolster what I’ve struggled to do with project teams for years.  The Principles make sense to me. Using the principles as a framework to make decisions makes sense to me. Learning from failure is simply wisdom.  I’ve put off blogging about my experiences in Agile for some time for many reasons, the first and foremost being that I approach the methodology practically and not philosophically. My perspective doesn’t leave much room for extensive pontification. I was recently reminded not to discount the value of my own voice. As an agile professional I admit a fair bit of shame in receiving that criticism.  In response, here is my voice.