This is Johanna Rothman’s October 2026 Pragmatic Manager newsletter. The Unsubscribe link is at the bottom.
Are you tired of large decks of project status data? I hate them. Too often, the data is not relevant, or worse, the data actually lies. That leads people to watermelon status, where the project is green until very late. All of a sudden, the project is red—in big, big trouble. Large decks are the antithesis of short, sweet, and useful.
However, all project managers—regardless of your kind of project—have access to an immediate chart that is short, sweet, and useful. It might not be everything you need, but if you add human-focused stories, it might be much of what you need. That’s the cycle time time-series chart.
Cycle Time Time-Series Chart
This image at the top of this newsletter is a cycle time time-series chart. The chart shows the trends of cycle times as individual points (all those numbers if you read from left to right). (If you need more data, consider the charts in Velocity is Not Acceleration.)
The cycle time time-series chart has big red lines that explain the 50, 80, and 90th percentiles. While I hesitate to say anyone can predict the future, the percentiles help people see what has happened and what might happen in the future—in a short, sweet, and useful way. It invites conversations about why teams have outlying cycle times.
Just a little math can make the difference between being able to achieve project success and feeling as if you’re always behind.
And it’s surprisingly easy to make. It’s easier to read than your bank statement. And much easier to read than your company’s Profit and Loss statement. So if “math” intimidates you, please read on before you decide it’s too difficult.
This math does not work with velocity, because velocity is a made-up number. Velocity has no relevance to how long the work actually takes. See Measure Cycle Time, Not Velocity. You might also like How to Move from Story Points and Magical Thinking to Cycle Time for Decisions.
How the Little Bit of Math Works
There’s not much math here. If you can use a spreadsheet, you can calculate cycle time.
- First, count the number of days (cycle time) it takes your team to finish the work your team delivers to others. You might need to draw a value stream map. (There’s a blank map in Measure Cycle Time, Not Velocity for instructions.) Focus on outcomes for other people, such as people in the organization or customers. For feature teams, that’s features, support tickets, or anything else you finish for someone in the organization or a customer. Workgroups such as Customer Success might track fixes. HR might track decisions or training from plan to rollout. Managers might track decisions. Remember, track the time until you finish something others can use. If you use a tool, see if the tool will count all the in-progress days for you. If you use cards on the wall, add a tick mark for each day the work is in progress until you finish the work.
- Make a spreadsheet of this data: Days since project start, because this is a trend. Now, plot the item and its cycle time on the chart, as above. If your team is like most teams, you might have leftover work from the previous project. (Those are the long cycle times in the above chart.) Your cycle times might cluster at a higher number than this team’s clusters.
With the spreadsheet, the predictions almost write themselves.
Use the Time Series for Prediction
The most common question I hear for projects of any kind is this: When will it be done? That depends on the team’s cycle time and the questioner’s comfort with the various levels of predictability. I like to show 50%, 80%, or 90% predictabilities on the same chart, so the questioner can choose how comfortable they want to be.
Here’s what those predictability numbers mean for this chart:
- About half the time (50%), this team can finish an item in 3-4 days.
- If the questioner wants an 80% predictability, we have to increase the cycle time to 12-13 days.
- And for people who want a “guarantee,” I use the 90% predictability. This team’s 90% number is almost 20 days. If your agile team uses iterations, that’s often two full iterations. Or, the team has to work differently.
Those percentages vary a lot. That’s why human stories help with the short, sweet, and useful aspects of project data.
How Stories Help Explain the Data
The first thing that stood out to me about this chart was the number of items this team already had in flight before they started their project. You can see that from the longer cycle times around day 5 since Project Start. Why? Were they already behind before they started?
In a way, yes. This team was still finishing features from the previous project. They were “behind” because management kept changing the product strategy, so their WIP was very high. Every time management changed the product strategy, the roadmap changed. Roadmap changes changed the team’s backlog. And so on. That is why we need continual planning with everyone’s short cycle time, so managers and product leaders can change the corporate and product strategies more frequently.
However, strategy changes weren’t the only problem. This team did not always have the required skills. If they wanted people with those skills, they had to wait for other people to be available. (See Unearthing Your Project’s Delays for more detail.)
But there was one reason for the two 6-day cycle times (look at days 11, 12, 13 in the chart). The team had started those features early in the project. However, no one was responsible for collecting customer feedback for those features. When someone finally collected customer feedback, the team learned that the product leader did not understand what the customer wanted. Worse, the team did not understand the product leader’s or the customer’s desires.
Oops.
That new understanding led to a simpler definition of those features and faster cycle time. That was pure luck. The new understanding might have just as easily led to more complex features.
Even better, the project manager and product leader could collaborate on stories about how the customers used the product.
Human Stories Explain How Customers Use the Product
We use the term “stories” a lot in projects. That term is supposed to describe how a user would gain value from this feature. However, I see too many stories that say something like this: “As an architect, I want a database with this schema.” Or “As a tester, I want an API so I can use programmatic testing more easily.”
Those are not user stories. Those are tasks for a given level of the architecture. Component teams create those tasks to make their coupling visible. See Component Teams Create Coupling in Products and Organizations. In contrast, full cross-functional feature teams can create stories through the architecture. See How Long Are Your Iterations? Part 2 for what stories through the architecture look like.
Another alternative is to use human story structure: A character in a setting with a problem. What problem does the human have? How will this feature (or feature set) solve that problem? Are there contexts that will make this character more or less successful?
If your team uses tasks, consider moving to a human story structure. Yes, I used the human story structure above to explain why the cycle times varied.
Math Plus Stories: Short, Sweet, and Useful
A little math in the form of a cycle time time-series chart can help everyone see project progress. No big decks (the short part). Easy to put together (the sweet part). And useful for where we are now and a little prediction of where we might be in the future (the useful part).
If you add in human stories, now you have the why behind the work. Also short, sweet, and useful.
I use these ideas for my work all the time. You can, too.
Read More…
- Daniel Vacanti’s When Will It Be Done? and Actionable Agile Metrics for Predictability. (That page has all of Prateek’s and Daniel’s books. I highly recommend all of them.)
- All three of the Modern Management Made Easy books.
- Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility.
- Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver
- Agile and Lean Program Management: Scaling Collaboration Across the Organization
- Free Your Inner Nonfiction Writer: Educate, Influence, and Entertain Your Readers
- Effective Public Speaking: How to Use Content Marketing With Stories to Show Your Value
(If you have read but not yet reviewed my books, please leave a short review somewhere, such as Goodreads. Thank you in advance.)
Links of Interest
New to the newsletter? See previous issues. (I post these newsletters to my YouTube Channel a few days after I send them.)
Here are other links you might find useful:
- Managing Product Development Blog.
- Create an Adaptable Life Blog to see the weekly question.
- My Books. You can also buy my self-published ebooks and audiobooks on my store.
- Johanna’s Fiction
- My Substack about living with (as opposed to dying of) cancer. (You might have to navigate to the “cancer” section. I’m taking an agile approach to that Substack. Start a little, learn, change. What else would you expect?
- Tip Jar. (My newsletters will remain free. And I do want to offer you an option for you to show how much you value my work.)
Johanna
© 2026 Johanna Rothman
Pragmatic Manager: Vol 23, #10. ISSN: 2164-1196