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?




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

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.

Empowered Developers: Strength to Your User Persona!

Copyright Fusion Alliance

Agile principles put the power of quality and the definition of ‘enough’ in the hands of developers. Yes, the Product Owner and Stakeholders get final say, but the best way to optimize your developers’ strength is to give them the power to make decisions about how to best fulfill a User Story. The Agile principle is clear: “The best architectures, requirements, and designs emerge from self-organizing teams.”

My interpretation of this principle is that empowering a team allows them to create beyond your expectations. One oft-overlooked empowerment tool is the User Persona. Here is an example developed by our User Experience team:


Asking A Consultant For AGILE – Check Yourself For Success

When asking a consultant if they can run a project with Agile there are assumptions on both sides that will make or break satisfaction. In my experience, these factors have the most impact when entering into an agile consultant partnership on a project.


If so, make sure you discuss your methodology completely with the consultant, including which roles you expect them to fill. Agile methodologies vary widely, even those that fall under scrum.

If not, reconsider making a consulting project your first agile experience. The tools, vernacular and—more importantly—measures of success that you are accustomed to will likely be quite different. Don’t undervalue the debt of taking on a new methodology along with on-boarding a consultant.

DO YOU NEED AN AGILE COACH? Continue reading

User Stories? I Have No Users!

Innovation teams are often small, multifunctional crews tasked with constant prototyping.  Being open, communicative types, they find Agile useful for most projects.  Those teams often encounter a common prototyping pain point: Who writes user stories when we don’t have any users?  Agile hangs its hat on its ability to respond quickly to user feedback, to create user stories from that feedback, and to release features and content that address what users are demanding at that time.  When you are prototyping, however, you don’t usually have users and the traditional user story:

As a (user type/persona), I want to (insert desired action) so I can (insert revolutionary motivation here).

Without users to provide feedback, and without a product for anyone to provide feedback on, how do you address the issue of User Stories? Continue reading