I Asked Pictor About Cycle Time. It Asked Me Four Questions First.

I came in with a broad question. I left with a specific commitment, a clear definition of done, and a next step.

I'd been thinking about flow metrics for a while. We use ActionableAgile across our teams, we run Scrum, and I knew I wanted to baseline cycle time and eventually use it for forecasting. I just wasn't sure where to start.

So I asked Pictor. What happened over the next ten minutes is a better explanation of how pictor works than anything I could write about it directly.

Here's the full session — with a note before each shift explaining what pictor was doing and why.

The opening question

Me: how can I use flow metrics in my organisation?

A generic AI would have answered this immediately. A list of flow metrics. Definitions. Maybe a diagram. All correct. All useless without knowing anything about the situation.

Pictor didn't answer. It asked.

▲ Pictor (Expert): Before I point you toward specific metrics and how to implement them, a couple of quick questions to make sure the guidance is relevant:

What does your current visibility into work look like? Are you tracking anything today — cycle time, throughput, queue sizes — or starting from scratch?

What's prompting the question? Are you trying to improve predictability, find bottlenecks, have better conversations with stakeholders, or something else?

What's happening here: Pictor opened in Expert mode — it's a practical, operational question and that's the right starting point. But before giving guidance, it asked two things: what already exists, and what's the actual goal. Both shape the answer significantly. "Starting from scratch" and "already using ActionableAgile" require completely different responses.

Me: we just use actionableagile and I am exploring these metrics... also we would like to baseline our cycle time and use aging charts to improve our overall performance... reduce or stabilise cycle time first and use it for forecasting

Now Pictor has something to work with. And it shifts.

● Pictor (Coach): Good context — ActionableAgile is a solid tool for this, and you've already identified a sensible sequence: baseline first, stabilise, then forecast. That's the right order.

A few more questions to sharpen the guidance:

When you say "reduce or stabilise cycle time" — do you have a sense of where the variability is coming from? Long tail items, specific workflow stages, or is it more unpredictable across the board?

What does your current workflow look like — are you running Kanban, Scrum, or something hybrid?

Who are the key stakeholders for the forecasting conversation — is this internal team planning, or external commitments to customers/leadership?

What's happening here: Pictor shifted to Coach mode. Not because the question became philosophical — but because the right move now wasn't to give a framework, it was to deepen the understanding of the situation before doing so. Three more questions, each one surfacing a variable that would change the guidance: variability source, workflow type, stakeholder context. None of this is small talk. Each answer narrows what "good guidance" actually looks like.

Me: currently not a clear workflow across teams... and we use scrum... forecasting is for the future for internal stakeholders

● Pictor (Coach): That's helpful context. "Not a clear workflow across teams" is actually important information — it affects how you interpret the metrics, so worth keeping in mind.

One more thing before we explore options:

When you say "not a clear workflow across teams" — do you mean each team has defined their own workflow differently, or that the workflow states themselves are vague or inconsistently used within teams?

What's happening here: Pictor caught something in the answer that most people would gloss over. "Not a clear workflow across teams" could mean two very different things — teams with different workflows, or teams with undefined workflows. The distinction matters enormously for how you interpret cycle time data. This is the question beneath the question.

Me: yes each team has a different workflow

● Pictor (Coach): Got it — so each team has their own workflow definition, which means your cycle time data isn't directly comparable across teams yet. That's a common starting point, and it's workable.

Let me make sure I've captured the full picture before we explore how to approach this:

— You're running Scrum across multiple teams
— Each team has their own workflow definition in ActionableAgile
— You want to baseline cycle time, use aging charts to surface problems, stabilise cycle time, then move toward forecasting for internal stakeholders

Is that an accurate summary, or am I missing something?

What's happening here: Before giving any guidance, Pictor paused to reflect the full situation back. This is a coaching move — it makes sure nothing has been misread, and it gives the practitioner a chance to hear their own situation summarised cleanly. In a human coaching conversation, this is where you'd often hear "actually, I left something out."

Me: yes

And now — only now — Pictor gave the guidance.

▲ Pictor (Expert): Good. Here's how I'd think about sequencing this:

Step 1: Baseline cycle time per team
Before trying to improve anything, get 2–3 sprints (minimum) of clean cycle time data per team. In ActionableAgile, look at your cycle time scatterplot — you're not looking for a number yet, you're looking at the shape. Wide spread = high variability. Tight cluster = more predictable. This is your starting point.

Don't aggregate across teams yet — their different workflow definitions make comparison meaningless at this stage.

Step 2: Use aging charts to find the problems
The aging work in process chart in ActionableAgile is your diagnostic tool. Items sitting above the 85th percentile line are your immediate focus — these are the ones inflating your cycle time and creating unpredictability. Ask per item: why is this aging? That conversation surfaces your real blockers — dependencies, unclear requirements, waiting states.

Do this in your daily standup or a separate flow review.

Step 3: Stabilise before you optimise
Resist the urge to target a specific cycle time number too early. Focus first on reducing the long tail — those outlier items that skew everything. When your scatterplot starts tightening, your percentile lines become reliable enough to use for forecasting.

Step 4: Forecasting
Once you have stable cycle time data, ActionableAgile's Monte Carlo simulation gives you probabilistic forecasts — "based on current throughput, there's an 85% chance this will be done by X date." That's a much more honest conversation with internal stakeholders than a sprint commitment.

What feels most uncertain to you in this sequence?

What's happening here: Pictor shifted back to Expert to deliver the guidance — four clear steps, sequenced correctly, with specific ActionableAgile references. Notice the last line: it didn't stop there. It immediately opened the floor to what's unclear. This is deliberate — the guidance isn't a monologue, it's a checkpoint.

Me: all steps are clear

● Pictor (Coach): Good. So what's your next concrete step — which team are you starting with, and when?

What's happening here: Pictor shifted to Coach mode to move from understanding to commitment. "All steps are clear" is not an action. Pictor noticed that and asked for one.

Me: start with baselining as you have recommended by end of current month!

● Pictor (Coach): Good. To make that concrete:

Which team are you starting with, and do they have enough historical data in ActionableAgile to baseline from, or will you be collecting from this point forward?

Me: with team alpha... we have quite a few sprints already with that team

● Pictor (Coach): Perfect — historical data makes this much faster.

So your action: baseline Team Alpha's cycle time scatterplot in ActionableAgile by end of month, using existing sprint data.

Who else needs to know about this plan — is this something you're driving alone or do you need to loop in a team lead or Scrum Master?

Me: I'll involve my team. I am the scrum master

● Pictor (Coach): Good — you have everything you need to move forward.

One last thing: how will you know the baseline is done? What does "complete" look like for you by end of month?

Me: not sure... any ideas?

Here's something interesting: I didn't know the answer. So Pictor shifted back to Expert to fill the gap — not to take over, but to give me what I needed to move forward.

▲ Pictor (Expert): A baseline is complete when you can answer three questions from the data:

What is Team Alpha's median cycle time? (the 50th percentile line in ActionableAgile)

What is the spread? (distance between 50th and 85th percentile — tells you variability)

Are there obvious outliers? (items above 85th percentile that need investigation)

When you can answer all three, you have your baseline.

Does that feel like a clear enough definition of done?

Me: awesome!

● Pictor (Coach): Great. So to recap your commitment:

Baseline Team Alpha's cycle time in ActionableAgile by end of month — you'll know it's done when you can answer those three questions about median, spread, and outliers. Your team is involved, and you're the Scrum Master driving it.

Good luck — come back when you have the data and we'll look at what it's telling you.

What just happened

I came in with a broad question. I left with a specific commitment, a clear definition of done, and a concrete next step.

Pictor moved between Expert and Coach six times across that conversation — not randomly, but in response to what the moment required. Expert when I needed structure or a knowledge gap filled. Coach when I needed to think, decide, or commit.

I didn't manage any of that. I just answered the questions.

That's the point. A good coaching conversation doesn't ask you to manage the process. It asks you to show up honestly and think clearly. The structure takes care of itself.

If you're working on flow metrics — or any Agile challenge you've been circling without a clear next step — this is what a session looks like.

Try Pictor Free →

Questions about flow metrics or ActionableAgile? Reach us at info@yourpaths.eu — or just ask Pictor directly.