View this email in your browser

Forecasting and Data Newsletter by Troy Magennis
Charting with Outcomes in Mind - My process and an example of building charts that matter.

Thanks for subscribing, and if you haven't yet (this newsletter was forwarded to you, or you clicked a link somewhere) consider subscribing: Subscribe here

If you like this content, please forward it to a colleague. 

If you didn't like this content, please email me why: Troy Magennis.

In this newsletter:

  1. Coming workshops and events you might be interested in.
  2. Article: Charting with Outcomes in Mind
  3. New Tool: Introducing "Blocked" Blocker and Dependency Tool
  4. About Focused Objective and Troy Magennis
Got Metric or Forecasting Questions? Contact Me

Coming Workshops and Events

"Register once, attend many times" 
Monthly schedule, join next month as well
Attend online, and get a free 1-hour 1:1
Your context and questions are important
All sessions are recorded 
English is sometimes a barrier. Relax and replay later.

MONTHLY (online) Training
Practical Forecasting Essentials (online)
Practical product features and portfolio probabilistic forecasting.

Using the Monte Carlo Throughput Forecasting Spreadsheets
This two-hour online power-session discusses how to use the throughput and velocity forecasting spreadsheets.

Team Metrics: Using the Team Dashboard Spreadsheet
This two-hour power-session discusses getting started and using the Team Dashboard spreadsheet.

Prioritization and Cost of Delay Calculation
Prioritization and Cost of Delay Calculation Power Session

Capturing and Managing Blockers and Dependencies using "Blocked"
Free webinar on using "Blocked" blocker and dependency management application to capture and manage blockers and dependencies using analytics.

Article: Charting with Outcomes in Mind

With everyone having access to Excel, Tableau, Power BI, Alteryx, etc. charts are more and more commonly displayed during meetings and in tools. The downside of everyone making charts is that many of these charts aren't very good. They don't have a reason for being, and the viewers most often don't understand what they are expected to do with those charts. This article describes the process I use to design charts that make a meaningful contribution to achieving intended outcomes.

This article is a worked example of how I created the charts and analytics in "Blocked" my new blocker and dependency management tool. I used this process to drive all of the product decisions, and want to share the process in case you find it useful.

Before touching the data and charting tool, you need to have an outcome in mind. The biggest failure in charting is not knowing what you want to achieve by charting that data. The viewers gaze longingly at the beautiful lines you drew expecting divine inspiration to hit them, and action to follow. When you get someone's attention, make it count. If you don't know what you want, the viewer won't either. Start by coming up with your intended outcomes.

When designing "Blocked" the blocker and dependency management application I started with the following outcomes in mind -

  1. Lower work item and feature delivery lead-time
  2. Fewer Blocked items
  3. The smoother more predictable flow of items
From the listed outcomes, I created as many decisions as I could that if people made (well) would cause those outcomes to be more likely. It's hard, you have to put yourself in the shoes of the other people, and think, what do I need them to decide to do as a verb to reach those outcomes. Asking them what decisions they make day to day now, or observe the decisions they make in meetings will give you a starting point.

For the "Blocked" outcomes, here is the list of decisions I came up with -
  1. To unblock blocked work faster by taking action
  2. Fix the causes of blocked items to avoid them in the future
Thinking from a decision perspective, what insights/AHA's do those people need to see in order to make that decision. What information if they knew, would cause the decision to be made. If you are following, you can probably pick-up that the job of our charts is to make these insights UN-MISSABLE and OBVIOUS. Anything that doesn't support the viewer seeing these insights is noise and likely impeding seeing the intended insights (doing more harm than good).

For "Blocked" here are the insights I thought supported the decisions -
  1. I need to know I'm blocking someone
  2. I need others to know I'm blocked
  3. I need to know when a blocker affecting me is resolved
  4. We have an abnormal number of open blockers
  5. What blocker is most urgent to resolve next
  6. The most common and impactful causes of blockers
  7. Did our process changes make an impact on reducing blockers?
Phew. That's a lot of insights. I find for most decisions people make they draw on two to three sources of insight, so I keep brainstorming until I get 2-3 insights per decision, so we are about right with six insights. Now. we can think of charts!

We are now at the first responsible moment to think about charts. The ONLY goal is to build a chart that makes the chosen insights obvious. You might need to find a way to capture that data (or at least a sample of the data) required to show those insights. In the case of "Blocked" I didn't find this data accessible in Jira or Azure DevOps, so decided to offer one. And then, and only then could I chart that data to show these insights. But, by knowing the insights that mattered, I simplified data entry to JUST NECESSARY to build the charts.

My measures were -
1. Blockers ON MY team and because of MY TEAM
2. Blocker urgency and age
3. Blockers in progress trends
4. Blocker causes by quantity and impact
5. What teams depend (block) on each other the most

I use a simple post-it note Miro or physical canvas. I put Outcomes - Decisions - Insights - Measures as titles, and start from the outcomes. Here is my canvas for "Blocked" the app.

In "Blocked" it's going to take some time to give every insight its day in the sun, but I've made a start with the following charts in the analytics tab. I like to think my development methodology was INSIGHT-DRIVEN-DESIGN, and hopefully, you will now understand how I linked the analytics to outcomes.

Firstly - a chart wasn't the right tool for the insight, what blockers should I resolve next, a list was needed. So, all open blockers filtered by the team are sorted top to bottom by urgency and age -

Seeing the trend of open and resolved blockers over time for a team gives the insight, "is this week abnormal," I chose a simple column-chart trended over time, color-coded by "age" so the teams can see if blockers are not being resolved in the usual lead-time.

And the determine what reasons work is blocked, I used a slope-graph that gives ranking and CHANGE over a time period (this case monthly). If a process has changed, I'd expect a decrease in impact by the tags associated with that cause/fix.

As you can see, the process for designing charts needs to have an outcome in mind before we start doodling with charts. You need to consider exactly what insights to highlight so that people make better decisions. Leave out anything that isn't related to insight, and charts begin to be useful.
Register for free - Capturing and Managing Blockers and Dependencies using "Blocked" webinar
New tool: "Blocked" Blocker and Dependency Management
I'm really excited to introduce my latest baby, "Blocked" a web application for capturing, managing, and eliminating blockers and team dependencies.


About Focused Objective and Troy Magennis
I offer training and consulting on Forecasting and Metrics related to Agile planning. Come along to a training workshop or schedule a call to discuss how a little bit of mathematical and data magic might improve your product delivery flow.
See all of my workshops and free tools on the Focused Objective website.

Got Metric or Forecasting Questions? Contact Me
Copyright © 2020 Focused Objective LLC, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp