Copy
View this email in your browser

Forecasting and Data Newsletter by Troy Magennis
Five Work Item Elements to Capture

In this newsletter:

  1. Coming workshops and events you might be interested in.
  2. Article: What Data to Capture - five work item elements 
  3. Myth of the Month - cycle time and lead time definitions
  4. Tool of the Month - cycle time adjustment spreadsheet
  5. About Focused Objective and Troy Magennis

Thanks for subscribing, and if you haven't yet, 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.

Got Metric or Forecasting Questions? Contact Me

Coming Workshops and Events


5 places left: San Francisco 6-7th February
Chicago Forecasting + Metrics 9-10th March
Atlanta Flight Levels Architecture 12-13th March 
Toronto Forecasting + Metrics 26-27th March <-- popular
Lean Agile London Conference 27-28th April
London Forecasting + Metrics 30th April
Free Months Call on Metrics
Training Schedule
Free zoom Call: Ask Me Anything on Metrics & Forecasting
All upcoming workshops in a city near you (or ask for one)

Article: Five Work Item Data Elements to Capture

These five data elements are good starting points for necessary data elements to collect for each item tracked in tools or on paper. These five elements are the table stakes for any significant data measurement usefulness. On most engagements, I find a way to get these 5 pieces of data from the many systems they have (yes, there is always more than one!). From these 5 data elements, all of the major flow metrics can be computed. 

1. Delivered Date

The date a “customer” was first able to utilize or use this item. Sometimes the data the customer delivered date is hard to get so, start with the date that is as close to that point as you can (often this is development complete if I'm honest). 

Questions you can answer with this date -

  • How much is delivered? (absent of value, but it's a start)

  • How predictable is work delivered?

  • How long would it take to deliver 10 more items?

  • How long until the next item delivers after the prior one? Takt time.

Teams often capture this date with high quality. It seems people like to get credit for delivering work (but the rest of the elements we cover won’t be so carefully captured).
 

2. Development Started Date

The date development work started on this item. Most often used to start the clock on development “cycle-time” = delivery date  - development start date

Questions you can answer with this date (and the other data mentioned prior) -

  • How long from Development start to delivery. Often called Cycle time?

  • How much work in progress?

  • How old are work in progress items? 

This date is often poorly and inconsistently captured. Tools often don’t capture this date value, but something close; the sprint work was committed, or the date added to a backlog. The best date is the date development work begins and would be work in progress for the development system.
 

3. Work Item Type

An indication of work type. Most often used to categorize similar items into a grouping that makes sense to compare against each other. Make sure the rework (defect) types are identifiable from planned work.

Questions you can answer with work type (and all prior) -

  • Segmenting all of the prior metrics (throughput, WIP, cycle-time) by work type

  • How much of each work type is there? (for example percentage of each type)

  • How much planned versus unplanned is there? (for example defect ratio) 

Either well captured or not captured at all. Tools often default this value and, it isn’t changed, or users create tens of types that don’t make ideal segments to track. At a minimum, define the criteria to categorize consistently -

  1. Planned work

  2. Unplanned work

  3. Rework (defects)
     

4. Priority or Preferred Delivery Order

An indication of what work there is an advantage to deliver before another item of lower priority. Priority helps teams determine a start order that serves the customer well and maximizes value flow. Teams’ inability to start work in priority order is an indication of lower customer value delivered. A typical pattern is that there are system constraints that inhibit starting or delivering work in this order, often dependencies on other busy teams or unplanned work jumping the queue. 

Questions you can answer with work priority (and all prior elements) -

  • Segmenting all of the prior metrics by priority. 

  • Are we delivering work in the right order or with some correlation to priority?

  • What work doesn’t have a priority assigned, and should it? 

Priority value assigned to work items is the bluntest instrument to determine high-value flow (or not). Organizations without clear policies (other than who screams the loudest) find this difficult at first. Learning the reasons work is delivered in a less ideal order is a fast way to identify where the delivery system is faltering - making this a super valuable data element to capture.
 

5. Committed “To-Do” Date 

The date that work is committed to be delivered, especially in the eyes of a customer. Most often used to start the clock on a stakeholder expectation of “lead-time” = delivery date  - committed date. Without the committed date, we could improve the development time (cycle-time) but disappoint customers or stakeholders by having those items sit idle for long periods until we started them.  

Questions you can answer with the committed date (and prior elements) -

  • How long from Committed to delivery. Often called Lead-time.

  • How much committed in progress?

  • How old are items in the committed in progress? 

For some teams, this date and the work item creation date are the same. For helpdesk tickets, the creation date of the ticket is the date and time they thought their problem would be solved. Development teams have (hopefully) many ideas in their backlog that are still options, not commitments. If we sharted the lead-time clock for these options at the item creation date, the lead-time we calculate wouldn’t teach us much about our delivery system flow. Discuss in your teams what “committed” means and capture that date on your work items.

Myth of the Month: Cycle time and Lead time are defined and agreed terms 

THERE IS NO STANDARD for cycle time and lead time, so you need to be very explicit about your boundaries internally to your organization! Here are my common definitions, but even these aren't universally agreed! This image also shows where I go looking for ways to reduce *-time depending on what state has the longest proportion to the total.

Tool of the Month - Cycle Time Adjustment

From either cycle time, days OR Start Date and End Date this spreadsheet extrapolate and computes workdays and calendar days. This is important if analyzing lead-time data for issues. If work crosses a weekend boundary, it might look worse than it was (or not if you are a customer) I find I need to do analysis and forecasts with and without weekends and this is my tool to do that conversion. Its actually more complex than you think, this spreadsheet uses some statistical extrapolation to approximate in some cases. Love feedback.
Download the Cycle Time Adjustment Spreadsheet (it's free)
See all my free spreadsheets and tools

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
Twitter
Website
Email
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.