How to Move from Story Points and Magical Thinking to Cycle Time for Decisions

Are you trying to use story points for estimation? If so, you might have encountered these problems:

• Story points reflect the ideal thinking of the team, not the actual experience of the team.
• Your managers don't want story points—they want durations and dates.
• In the absence of sufficient information, everyone makes up fiction (human stories) about what they want to happen.

Story points require magical thinking. Cycle time does not. That's why I recommend all teams (including management teams) measure cycle time, not velocity.

However, too often, we don't like what cycle time tells us. But that's our reality. And if we don't like reality, we can change it. But we need to see it first.

See Cycle Time Reality

After a particularly tense retrospective, one team decided to measure and chart their cycle time. The first image on the left is their raw spreadsheet data. (Yes, this is real data from a client, and I anonymized it. For my European colleagues: this is US date format, where the month is first, followed by the day.)

Note several things about this data:

• No one finishes anything on the weekend. So yes, cycle time includes the weekends.
• No one starts anything on the weekend. Because normal humans, including this team, do not work on the weekends. Another reason why cycle time includes weekends.
• Their cycle time is not so predictable, even with keeping their WIP fairly low.

But you might have trouble seeing all of that in columns. Here's a scatter plot:

Yes, I realize those little dots are hard to see, so if anyone knows how to fix this in Excel, I would love to know. Sigh.)

Now, as to how long things took?

This team kept its WIP low, just two items at a time. (They collaborated, mostly by pairing and swarming.) And every single planned item was supposedly a relative estimation of either “3” or “5.” (It doesn't matter what 3 or 5 means. Every single item was either a 3 or a 5.) They thought that would make them predictable.

But they are not predictable. Partly because they also do production support—but those are mostly cycle times of 2-3 days. Why did velocity create such magical thinking around how long things take?

Cycle Time Exposes Magical Thinking

Velocity allowed the team to hand-wave around who would do what and when. They were new to this code base, so they tripped over unknowns in the code and tests. At one point (for the story they finished on Jan 19), they realized no one in the team had the necessary expertise to review the code, never mind adequately test it. The team spent most of a week educating themselves. In parallel, their project manager spent that same week finding people with that expertise and then persuading those people's managers that this team needed their expertise.

None of that is part of velocity and relative estimation and no one planned it. Yet, the team needed to do it.

Worse, relative estimation assumes velocity will stabilize. But that's not this team's experience. This team now shows their confidence level to management.

Show and Choose Your Confidence Level

This chart shows the previous cycle time chart, but with 50%, 80%, and 90% confidence levels. The 50% line is solid, the 80% is big dashes, and the 90% is small dashes.

Since the team is only three months into this project, and their cycle time is not as controlled as they would like, they show this chart to their managers when the managers want an estimate. The agile project manager asks,

“What percentage confidence are you comfortable with for a given item? If you want a 50% confidence, that's about a week. If you want 80%, that's about two weeks. And if you really want to be sure, that's 90%, that's almost three weeks.”

No one has to translate story points (or acorns or apples) to days or weeks. The team can use their data to predict what they can do next. You can do this too.

How to Move from Story Points to Cycle Time

Here's how I created the cycle time series with this team's data:

1. Start a new spreadsheet. Use the columns I recommend, with start date, end date, and cycle time.
2. Get as much data as possible, preferably, at least three months of data. Add in the start and end dates. If your tool calculates cycle time, use that. (Check that the calculation is correct.)
3. Here's how to do the cycle time calculation if you have a lot of data and no tool:
   1. The formula is End Date minus Start Date.
   2. However, if you have a one-day story (and yes, I love one-day stories), you might have big fat zero where you need a one.
   3. So, here's the formula I used in the cycle time column: =IF((B3-A3)=0,”1″, (B3-A3)). That formula says: If the subtraction gives an answer of zero, change that to a one. Otherwise, use the results of the formula. (I practically broke my arm patting myself on the back for that one.)
   4. Alternatively, you could just add a 1 to all the cycle times. But that didn't feel right for this team because they had so many stories where their cycle time was less than four days.

Choose a scatter plot for your cycle time data. Make sure your X-axis is the date, so everyone can see if your cycle time has settled down to bouncing between some small set of numbers.

Either eyeball or count the number of stories to give you the 50, 80, 90% lines. To be honest, I eyeballed. You don't need perfection—you need to tell the story of your cycle time.

This team is keeping their first six weeks of data, because they don't know what else they don't know. But they do know that magical thinking does not work for them.

Cycle Time, Not Magical Thinking, Allows Much Better Decisions

If you're supposed to predict future work, cycle time can tell you. Relative estimation cannot. (Yes, I said this in Predicting the Unpredictable and Create Your Successful Agile Project.)

If you're not sure about cycle time, read Flow Metrics and Why They Matter to Teams and Managers. And if you have a facilitative role in your team, such as a Scrum Master or agile coach who insists on relative estimation, read the posts about flow metrics.

Friends don't let friends use relative estimation because that's magical thinking. Instead, learn how to calculate and use cycle time.

Do you want a more rigorous explanation? Read Daniel Vacanti's and Prateek Singh's books.