• Skip to main content
  • Skip to header right navigation
  • Skip to site footer
  • Home
  • About
  • Newsletter
  • Blog
  • Contact

Thoughts on Outcome Based Metrics

Chris Matts recently wrote a post about Time to Value as an Outcome based Process Metric . I have some thoughts about the topic and decided to write them up here. I could have recorded a comment, but based on past history with my comments on Chris’ post (he accidentally deleted it), I decided to put my thoughts here for safe keeping. Plus, my thoughts may end up being a little lengthy, so it seemed better to record them here.

In the post, Chris suggested three outcome based metrics:

  • A quality metric – i.e. number of defects escaping to production
  • A value metric – profit, revenue, number of customers, or any other SMART Goal
  • A time to value metric – the main topic of Chris’ post.

Cycle time is a good way to capture time to value, however the tricky part is figuring out when the clock starts (i.e. when does the cycle begin). As Chris points out, in projects using iterations, the clock is typically started at the beginning of the iteration in which the team chooses to deliver a given item. This measure gives a good feel for the timing of delivery investment, but it ignores any analysis work that is done. This also ignores if there is a long queue that occurs between when an item is initially identified and when it is actually delivered. For example, someone could identify a need in January, place it in a backlog, and not see the results for several months depending on the length of the backlog and where the item falls on the priority list.

Ignoring this timeframe could mask an issue – that ideas linger for quite a while before becoming realized. This occurs frequently in internal development efforts, where the work is often organized as projects and a set of items are all related to a change needed to support a change in business process. Based on what Chris suggests, the longer the period between when an item is identified via even a small investment in analysis, the more risk the effort incurs. This is, in effect, an argument for not doing even a little bit of analysis before it’s time, which can be a tricky balancing act to figure out the appropriate amount of analysis to understand the various chunks of value. Many organizations still want to organize their work in projects, so the question remains – when do we start the clock? I think there’s validity to starting the clock shortly after an item is identified so that you see the long time the item spends in the queue in some cases. If nothing else, this may provide some ammunition for changing the way organizations approach work into smaller bits.

As with Chris, I’d be interested in hearing other’s experience and thoughts on the notes above.

Category: Product OwnershipTag: Uncategorized

About KentMcDonald

Writer & product manager helping product people deliver powerful internal products. #Ubersherpa to my family, listens to jazz and podcasts (but not necessarily podcasts about jazz), and collects national parks.

Previous Post: « BDD and the Business Analyst
Next Post: Do We Need (Another) Business Analysis Certification? »

Sidebar

Recent Posts

  • This meeting should be an email, but will people read it?
  • Story Splitting
  • Example Mapping
  • Usability Testing
  • Sprint Reviews

Categories

  • Book Review
  • Business Analysis
  • Experience Report
  • Inside Product
  • KentMcDonald.com
  • Portfolio Management
  • Product Management
  • Product Ownership
  • Product Roles
  • Technique Brief
  • Uncategorized

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org
Newsletter

Get a weekly email with hand-picked resources for product people in tech-enabled organizations.

Subscribe

  • Facebook
  • Twitter
  • Pinterest
  • LinkedIn
  • YouTube

Copyright © 2022 · All Rights Reserved · Powered by Mai Theme

Go to mobile version