Lead time / Cycle time report for PBIs

Edit Subject

Hi Jaakko,
We've had an idea for such a report for quite a while. In the lean world, this is often called "cycle time", so i updated the title of your post to reflect that.

I'm curious if others would find this useful.

Hi Victor

I was thinking that calculation would be divided by steps so average lead time for creation -> in progress, in progress -> done and average of those. I agree that some lo prio stories will make lead time to look much worse than it actually is so starting calculation from release start date would be good fix for those problems. Additionally user could deselect some stories that affect average too much but that is not very important.

Jaakko

This report is now available as part of ScrumWorks Pro 4.5:
http://danube.com/scrumworks/pro/rele...

Happy Scrumming!

The SW Cycle Time Report is not quite correct, and very confusing.

- Lead Time in Lean parlance is from the time the item is created until it gets to the customer.

- Cycle Time in Scrum parlance is from the time it is COMMITTED to in a Sprint until it is ACCEPTED by the Product Owner.

SW Cycle Time report has 3 numbers. I'd like definitions on each;

Not Started: Okay, is this from the moment the item is created in the PB until someone does hour one on a task? Or is it from the moment it enters a Sprint until someone logs hour one on a task?
WIP: Is this just when an item is in that middle "Doing" category?
Created to Done: Sounds like Lead Time to me..... but since the Report is "Cycle Time" perhaps it is "Committed to Accepted" - true cyle time. Which is it? It is certainly not the sum of the previous two numbers, which is what intuitively you'd think it would be from the format of the report.

I suggest:
1) Created to Sprint Commitment: Time a story queues waiting before getting to the Technical Team.
2) To Do: Time a story is in one or more Sprints before being begun.
3) Doing: Time story is actively being worked on, i.e. WIP or begun but not finished.
4) Cycle Time: Time from Committment to Accepted, i.e To Do + WIP. Ideally the
equivalent of one Sprint or less, sometimes spanning multiple Sprints.
5) Lead Time: Created to Potentially Releaseable.

HELP!

I've contacted Support, and they filed a ticket

and then emailed a non-responsive answer.

Hi Karen,

Sorry about the delay in reply, this is one of those bad summer weeks that sometimes happen where there aren't as many people around to answer questions as we would like.

I was just about to respond to your voice mail that was routed my way when I noticed this. This is the official answer:

The bars in a Backlog Item Cycle Time module are a representation of the average number of days that all backlog items in the selected product spent in the following states: Not Started, In Progress and Created to Done

Not Started: The average number of days across all backlog items between backlog item creation and the first day of the first sprint from this release. Backlog items not put into a sprint use today as the first day in sprint to indicate lingering unstarted backlog items.

In Progress: The average number of days across all backlog items between the first time backlog items were placed into a sprint from this release and the day that they were marked done. Backlog items are not currently in a sprint are not counted for this value. Backlog items that are in sprint and not yet done are counted using today's date as the "done date" to indicate lingering unfinished backlog items.

Created to Done: The average number of days across all backlog items between creation and the day that they were marked done. Backlog items that are not done are not counted for this value.

When creating or modifying a Backlog Items Cycle Time module, the following attributes of the module can be selected on the configuration dialog:

Releases Filter: Select releases in this filter to include only Product Backlog Items from the selected Releases.

I wanted to get that in there and then get this one added. If this isn't right, or not what you are experiencing just let me know. I'm stuck the rest of this week in a meeting room that seems to have no cell reception or internet connection, but when I am back in my hotel room I will make sure to check on this thread.

Hmmmmm. Here’s my translation of what you wrote:
- Not Started: Uncommitted items hanging out in the Product Backlog. Malingering items – okay.
- Created to Done: Lean Lead Time. Okay.
- In Progress: Cycle time, almost...... why would you use today’s date to mark things “done?”

** Okay: The average number of days across all backlog items between the first time backlog items were placed into a sprint from this release and the day that they were marked done
** Do not get it: Backlog items that are in sprint and not yet done are counted using today's date as the "done date" to indicate lingering unfinished backlog items

Thank you for any clarity you can bring to this.

I suggest that any item in a sprint but not "done" should not be factored into cycle time. Cycle Time by definition indicates a beginning and end state/date.

There have been some changes made to the status of Backlog Items.

What version of ScrumWorks are you currently on? You should be able to check by selecting Help About ScrumWorks Pro from the Desktop Client. Or see it at the bottom of the login page.

ScrumWorks Pro 5.1.0

I think some changes may have been made to them in 5.2. The information I gave above is for the newest release of 6.0. I am checking with the Product Owner on that.

Hi Karen,

You said:
"I suggest that any item in a sprint but not "done" should not be factored into cycle time. Cycle Time by definition indicates a beginning and end state/date."

I understand your point and we should probably make the change to the report. The only issue is what to do with items sitting idle in a sprint “undone” for a very long time. They may never be factored into the calculation if they are never marked done...

We see this scenario rather frequently - items "abandoned" in a sprint without a "done" resolution. That is why we built this report factor "unresolved" items into the calculation.

Nevertheless, your point seems valid since we are trying to compensate for users misusing the product by leaving items in an In Progress state by mistake.

Thanks for the suggestion.
-- Victor Szalvay
ScrumWorks Product Owner

Hi Karen,

Here's some additional detail to support the documentation on this report:
http://danube.com/docs/scrumworks/pro...

I admit that the doc is not well written and needs clarification so I commit to improving the docs and making it more clear. After comparing the docs to our internal test case records and business logic decisions, here is my clarification of how the three lines are calculated:

Not Started: The average number of days across all backlog items between backlog item creation and the first day of the first sprint from this release. Backlog items not put into a sprint use today as the first day in sprint to indicate lingering unstarted backlog items.

This is a mouth full and it's poorly written, our bad. But what it means is that the Not Started column takes the average number of days across all PBIs between the time of creation and the first day of the first sprint a particular PBI was added to a sprint. We need this designation because an item could be in a sprint, then removed. In our view that item was started and is now in the "in progress" camp, even though it was placed back into the backlog. But as I said, this is poorly worded and needs changing.

In Progress: The average number of days across all backlog items between the first time backlog items were placed into a sprint from this release and the day that they were marked done. Backlog items are not currently in a sprint are not counted for this value. Backlog items that are in sprint and not yet done are counted using today's date as the "done date" to indicate lingering unfinished backlog items.

Building on the explanation to the last section, again what we're saying here is that a PBI crosses a threshold as soon as it's associated with a team. From that point forward, until it's marked done, it counts toward the In Progress bar (average days in progress). Your point above is valid and I'm considering it but I still think there is a significant under accounting problem if people never mark a PBI done. Your suggestions on this point would be useful.

Created to Done: The average number of days across all backlog items between creation and the day that they were marked done. Backlog items that are not done are not counted for this value.

This one makes sense to me on reading it, but certainly let me know if it needs clarification in your view. Your point about this being lean lead time vs sprint lead time is something that's news to me. I'd be interested in your source on the mechanics of this report in scrum vs. lean contexts. At the time we created this report I was not aware of any such distinction being widely accepted. There was debate as to whether to use creation or inclusion in a target release - that I understand. But your version "committed to done" is actually what we are doing with the "In Progress" column anyway. So for your purposes, if you want "Scrum lead time", just ignore the first column, I guess.

I hope this helps,

-- Victor Szalvay
ScrumWorks Product Owner

Here's a concise definition re Lead Time v. Cycle Time.

http://leanandkanban.wordpress.com/20...

Much more here: http://www.bing.com/search?q=lead+tim...

I'm still struggling with what to do. I'm loathe to use your report, no matter how easy it is, because it is deceptive and has less than ideal labels. Plus, add a bunch of tasks on any given day, and you game the system - think Day 1 or 2 of a Sprint. Think of it like this. I want my chicken & baked potatoe to be cooked. My cooking time starts when I put it in the oven, and wends when it's "done" and removed from the oven. Counting it "done" when it's still raw, just because it is in the oven, isn't going to give me a valid cooking time.

I suggest WIP be labeled as Cycle Time and only counts Sprint Backlog Items that entered the WIP column and then progressed to Done.

Here's a concise definition re Lead Time v. Cycle Time.

http://leanandkanban.wordpress.com/20...

Much more here: http://www.bing.com/search?q=lead+tim...

I'm still struggling with what to do. I'm loathe to use your report, no matter how easy it is, because it is deceptive and has less than ideal labels. Plus, add a bunch of tasks on any given day, and you game the system - think Day 1 or 2 of a Sprint. Think of it like this. I want my chicken & baked potatoe to be cooked. My cooking time starts when I put it in the oven, and wends when it's "done" and removed from the oven. Counting it "done" when it's still raw, just because it is in the oven, isn't going to give me a valid cooking time.

I suggest WIP be labeled as Cycle Time and only counts Sprint Backlog Items that entered the WIP column and then progressed to Done.

Karen,
I'm coming around to your point and we'll change this report as follows:
- The In Progress bar will no longer include work that isn't done currently. That is, we'll ignore items in flight so that they won't bring down the average artificially.

Thanks for the blog link. I think the comments point out just how much confusion and non-standardization there is when it comes to lean metrics. But in general, I like your suggestion for changing the labels as follows:

- Currently: "Not Started"; Suggestion: perhaps remove this line?
- Curenntly: "In Progress"; Suggestion: "Cycle time" (time from sprint/team to done)
- Currently: "Done"; Suggestion: "Lead time" (sum of time from creation to done)

Or would you keep the NS bar? If so what label?

Thanks for your feedback, Karen.

Excellent! Good dialogue :)

While you are in there, could you do one more thing to make it User Friendly. Here it is in Story format.

As a Scrum Team, we would like to be able to see the progression of cycle time over the Release, so that we can track our improvement or lack thereof as a metric.

AC:
This is done when I can not only see a report with our current cycle time as of the date it is run, but can also see a report similar to the Velocity Report that gives us snapshots in time.

Re Not started...... not necessary. The two metrics that are most useful and similar are Lead Time and Cycle Time.

I agree, great dialogue and very useful feedback on this feature. Thanks for your time in helping us improve.

I can commit to the changes I outlined above but the historic snapshot will be a much more difficult thing to do because we have to data warehouse all those snapshots, something we're currently not doing. I don't disagree that it's a good feature but probably not something I can fit into this year's roadmap.

Thanks again Karen!

P.S. My focus has been on Cycle Time, and combining Cycle & Lead Time in one report is not a probelm..... but for the historic view, per my user story..... it could be confusing. Might want to have a separate reports, or at least think how to present both Lead Time and Cycle Time over multiple Sprints in one report with clarity.