ABC
1
2
Cycle Time Analysis Template
3
4
Instructions: What are these charts? How do I work them?
5
6
Why Track Cycle Time?
7
Relative size estimation and vigilant backlog maintenance are two of the keys to Scrum success. They're also pretty hard to talk about and explain outside of your team. An understanding of cycle times will help you (and others) to understand the importance of keeping a good, well groomed and estimated backlog, and the importance of breaking big, ill-defined "requirements" into smaller, estimable chunks. These practices lead to shorter cycle times, as well as better quality and control.

If you're thinking about experimenting with limiting WIP, then monitoring cycle time is essential in gauging the benefits (or detriment) of that.
8
9
How do I use this Template?
10
First, choose "Make a copy" from the "File" menu above. That copy will be saved to your own Google Docs account.

On that NEW doc (this one is not editable to you!), just use the "Input" Sheet. There's sample data in there to show you what goes where. Just replace all that. Names, Dates, everything that's in a WHITE cell.

The charts themselves are found on the "CHART: Cycle Time", "CHART: Variance", "CHART: Spectral Analysis" and "CHART: Story Size / Cycle" sheets.

11
Overwrite the content of the white cells, don't delete rows or the calcs in the grey cells!

12
By entering the User Story details (including start/finish dates), the charts will just happen. Use as many rows as you need to on the "Input" sheet, but remember:

13
Don't mess with the Grey Cells or the "Chart Data" sheet, as they prepare the input for the charts that follow.

14
By all means, experiment with the "Chart" sheets, and configure them to your own taste.
15
16
What do the charts show?
17
18
CHART: Cycle Time
19
Tracks: The cycle time of each user story over time.
20
This is simply the plotting of the cycle time for each story completed. Over time, you may see trends emerge. Dots that are consistently grouped together near the bottom of the chart are good (provided that you think your velocity is where it ought to be). That shows that work is getting through your system quickly.
21
22
CHART: Variance
23
Tracks: How close each user story’s cycle time is to the average for your team
24
Monitors consistency from your team. Very similar to the basic Cycle Time chart, with an average displayed. The line the centre is the average cycle time across all stories. The dots that surround it show how much variance from that average occurs over time.

Decide for yourself the value of monitoring and charting cycle time. I like to do it, but I’ve found that it can (at times) tell you things that you probably already know. For example, if you load up your iteration with small interface tweaks, then you’ll probably get low cycle times. Dedicate your sprint to some heavy lifting re-factoring, well…
25
26
CHART: Spectral Analysis
27
Tracks: The frequency of cycle times across all your stories.
28
If all your user stories were exactly the same “size” (for example), it’d be easier for you to predict the delivery date of each one. Knowing the most common cycle time of user stories you’ve completed can help you to become more consistent, as well as providing targets (“our most common cycle time for the last year is 6 days, let’s make it 5 days this time next year”).
29
30
CHART: Story Size / Cycle
31
Tracks: The number of days that user stories (of various sizes) take to get through the delivery process.
32
On this chart, each bubble is a completed user story. This team uses just three sizes, small, medium and large. Each bubble therefore, can be only one of three sizes (a small bubble indicates a small story etc.) The position of the bubble on the chart shows the cycle time for that particular story. The higher up the chart, the longer that story took to complete.

A brilliant team with a perfect crystal ball would produce a chart where all the large bubbles were at the top of the chart, and all the small bubbles were at the bottom, displaying a consistently accurate relationship between size estimation and cycle time. However, whilst this is generally true, there are frequent exceptions. Sometimes a large story is done very quickly, and sometimes a small story ends up taking much longer than expected. And yet, this team has a very consistent velocity.

This supports the notion that estimating quickly is an effective way of chopping out unnecessarily verbose and traditional planning sessions. The team knows deep down roughly how big a feature is. So get it out of them, get it on the card, get on with your day!
33
34
Let me know how you go!
35
36
You are free copy this doc, and use it in any way you like. Knock yourself out. It'd be great if you could post a link back to the blog (somewhere) if you find the charts give you some help at work!

37
http://scrumage.com/
38

If you find any errors, or think of ways to improve these charts, don't keep it to yourself. Any feedback at all is great.
39
40
Adrian
41
adfit11@gmail.com
42