Report a bug or idea without leaving the page. A "Report a bug or idea" button now lives in the footer of every page. Add a note, and attach a screenshot of the page with one click if it helps explain what happened. No more describing a broken layout in words alone.

Promote a subtask to its own item, or an item to its own milestone. When something you scoped as small turns out to need its own tracking and forecast, promote it up a level. Look for this icon in the item card's action row, between share and edit, and click it: . No recreating it from scratch, no losing its history.

Mermaid charts render in docs and blog posts. Pie, bar, and line charts written in standard Mermaid syntax now render inline, next to the flowcharts and sequence diagrams that already worked.

AI agents connected over MCP can now see an item's history, not just its current state. A new list_item_activity tool returns who did what and when: status changes, assignments, moves, the decision text behind a resolved highlight, and any commits or pull requests linked to the item if your repository is connected. Before this, an agent picking up an item had no way to know a decision had already been made days earlier.

Improved

The milestone picker remembers your last choice and lets you create one inline. Moving an item to a milestone no longer means abandoning the form to go create one first. Pick "New milestone" right there, or let the picker default to whichever one you used last.

Probability-line tooltips now show confidence percentiles, not just a date. Hovering a forecast marker tells you how likely that date is, not only what it is.

Planning a milestone is now limited to Owners and Project Leaders. Collaborators still add items, comment, and move work forward, but setting a milestone's plan and locking its scope is a leadership action.

Fixed

• Item cards collapse automatically the moment you start dragging one.
• Search resolves #GP-47 shortcuts directly, instead of requiring a full-text match.
• Watchers get an email the moment an item is marked Delivered, not only once it's Accepted.
• Standup shows a "Finish Milestone" button the moment there's nothing left to work on, instead of an empty screen.
• The watching page tells requesters apart by avatar, and adds a "Created by me" filter.
• Accepted items on the watching page collapse behind a toggle instead of staying in the main list.
• The CLI's MCP setup now supports Codex, not just Claude.
• Reinvited members no longer stay stuck disabled after accepting, and the last remaining Owner on a project can no longer be disabled or removed by mistake.
• The watching page's item list updates the moment you change an item from that page, instead of waiting for a refresh.
• Finishing a milestone's last item now shows the right "all done" view immediately, not after a reload.
• Trial projects can change seat count again, and the team filter dropdown no longer renders underneath the list.
• The onboarding wizard can be skipped.
• Browser extension links go straight to each store's listing instead of a generic page.
• A rare client-side crash from a malformed realtime update is gone, and the bug report dialog no longer looks frozen while it's capturing a screenshot.
• A crash or auth error now shows a proper page with a way to report it, instead of a blank screen.
• Clicking a milestone in the voting list now opens its detail drawer, instead of doing nothing.
• Sending an invite now validates the email and shows it as pending right away, instead of only after a refresh.
• Inbox and Icebox milestone cards are now equal height.
• Blocked/Question/Discussion item cards and Deadline items were nearly unreadable in dark mode. Both now use colors that meet contrast requirements.
• Inviting someone who's already an active member no longer creates an invite that can never be resolved. We also cleaned up an existing stuck invite this caused.
• The MCP server's OAuth discovery documents could come back with a stray newline in every URL, which broke stricter OAuth clients even though logins from GoalPath's own apps kept working.

For the full list, check the activity feed on any project you're a member of.

If you have worked with any project management tool, you know the pattern. You open the board in the morning, scan your items, close the tab, start coding. Three hours later someone asks "did you start that item?" and you realize you forgot to move it.

The board is in one window. Your code is in another. And the gap between them is where status updates go to die.

This is not a discipline problem. It's a proximity problem. The further your task list is from where you actually do the work, the less likely you are to keep it updated. And when items don't get updated, the forecasts drift, the progress reports are stale, and your team lead starts asking in Slack instead of checking the board.

So we put it in the sidebar

The GoalPath VS Code extension adds your assigned items directly to the editor sidebar. Not a webview, not an embedded browser. A native VS Code tree view that loads fast and stays in sync.

Two sections. My Work shows what's assigned to you, grouped by milestone. Upcoming shows what's available to pick up next from your active milestones.

Each item shows its current status. Items with subtasks expand to show them as checkboxes. Click to toggle, and the progress updates for your whole team in real time.

One click to progress

Hover an item and you see the next action. "Start" when you pick it up. "Finish" when the code is done. "Deliver" when it's ready for review.

This is where it makes a difference for your team. Because when status updates happen at the moment the work happens, the data in GoalPath is always fresh. Forecasts stay accurate. Progress reports reflect reality. Nobody needs to ask "where are we?" because the answer is already there.

For delivered items, you get Accept and Reject buttons instead. Rejecting prompts for a reason, which gets posted as a comment so the developer has context without a separate conversation.

Blockers get reported when they happen

Right-click any item to flag it as Blocked, Question, or Discussion. Type a quick explanation. Your team lead sees it in GoalPath immediately.

This matters because of timing. If flagging a blocker means opening a browser, finding the item, and writing a comment, most developers just keep pushing and mention it at the next standup. By then half a day is gone. When flagging is two clicks away in your editor, blockers surface hours earlier.

Everything from the keyboard

The command palette (Cmd+Shift+P) has all the GoalPath commands. Sign in, switch projects, add items, refresh. No mouse required.

Adding a new item works the same way. Pick the type, write a title, choose a milestone or send it to the inbox. Done in three steps without leaving your editor.

Setup takes 30 seconds

Install from the VS Code Marketplace. Click the GoalPath icon in the Activity Bar. Paste your API key (you can generate one in your profile). Pick your project.

If your repo already has a .goalpath file from the GoalPath CLI or MCP server, the project is selected automatically. Commit that file once and every developer on the team gets the same sidebar with zero configuration.

GoalPath goes where the developer is

This is the third integration we've built that meets developers in their existing tools. The Chrome extension captures bugs from the browser. The MCP server connects AI coding assistants to your backlog. And now the VS Code extension puts your task list in the sidebar.

The pattern is the same in all three: reduce the distance between doing the work and recording the work. When that distance is zero, the data stays fresh. When the data stays fresh, the forecasts are accurate. When the forecasts are accurate, stakeholders stop asking "where are we?" and start making decisions from the dashboard instead.

That is what we mean when we say the process is embedded in the tools you already use.

Install the VS Code extension. Free with any GoalPath plan.

If you have worked on a software team that takes delivery seriously, you have probably seen a cumulative flow diagram in a presentation at some point. A colorful stacked area chart, different bands for each state on the board, growing to the right as time passes. Someone pulls it out during a retrospective, points to where a band gets thick, and says "see, this is where we had a bottleneck in March."

That is a useful post-mortem. It is less useful when the band is widening right now and nobody notices until a milestone is already late.

The promise of CFDs and statistical process control is genuine: they can tell you whether your delivery process is stable, whether the variance you see is just noise, and whether a slowdown is a real signal worth acting on. The problem is that most teams do not have the time or tooling to build and maintain these charts continuously. They get generated once a quarter, analyzed by one person who read a Kanban book, and then forgotten.

GoalPath includes a cumulative flow diagram on the velocity analytics page with four bands (Not Started, Started, Finished, Accepted) over time, with daily or weekly granularity and milestone filtering. But the chart is only one layer. GoalPath also surfaces the same underlying data as structured diagnostics: WIP levels, flow time trends, aging work, and velocity variance. The chart shows you the shape. The diagnostics tell you what to do about it.

What a CFD is actually telling you

A cumulative flow diagram plots the number of work items in each state over time. The bands stack on top of each other. The bottom band is typically done items, growing steadily upward if work is actually finishing. The middle bands are your in-progress states. The top band is your backlog.

Three things are visible at a glance when a CFD is healthy:

Band width tells you work-in-progress at each stage. If the "In Review" band is thin and consistent, reviews are flowing. If it keeps getting thicker, work is queuing at review faster than it is being cleared.

Band slope tells you throughput. The slope of the topmost line of your "Done" band is your delivery rate. Steep slope means work is shipping. Flat line means it stopped.

Vertical distance between lines tells you cycle time. The gap between when work enters a state and when it exits is visible as vertical height on the chart. If that gap grows, items are spending longer in each stage.

The patterns you are looking for are divergence (bands widening unpredictably), stagnation (the done line going flat), and compression (bands narrowing, meaning one stage is starved of input). All three have different causes and different fixes.

The signal-vs-noise question

Statistical process control, which is the manufacturing discipline this analysis comes from, was developed by Walter Shewhart at Bell Labs in the 1920s. His insight was simple: some variation in a process is just noise, random fluctuation that you should not act on. Other variation is signal, something in the system actually changed, and you should find out what.

The way you tell them apart is control limits. You calculate the average of your process metric and the standard deviation. Anything within roughly three standard deviations of average is probably noise. Anything outside those limits is worth investigating.

For software delivery, the equivalent question is: when your velocity drops one week, is that a real signal to be concerned about? Or is it just normal fluctuation in a complex system?

Most teams never answer this rigorously. They see a slow week and either panic and add meetings, or dismiss it and miss a real problem developing. The answer depends on how much variance is normal for your team, which requires measuring variance over time, not just looking at last week.

Where teams actually get stuck

The practical failure mode is not that teams lack CFDs. It is that the data they need to diagnose problems lives spread across different places: the board shows current WIP, a spreadsheet tracks velocity, someone's notes have the context for why February was slow.

The "where are we?" sync exists precisely because this information is not connected in one place. You need a meeting to assemble the picture that the data already contains.

The ritual it spawns: a weekly or bi-weekly delivery review where someone manually aggregates the board state, eyeballs recent velocity, notes which items have been sitting a long time, and reports to leadership. This takes an hour of preparation and thirty minutes of meeting time. And it is still usually imprecise.

How GoalPath approaches this

GoalPath gives you the CFD itself, and then goes further. The chart is there when you want the visual. The diagnostics below surface the same signals without requiring you to interpret bands on a graph.

Flow load aging shows you which items in progress have been there the longest. In a CFD, an aging item shows up as a band that stays wide. In GoalPath, it shows up as an item flagged by how many days since it was started. You do not need to spot the pattern in a chart. The aging is surfaced directly against each item. Items that have been sitting too long are visible in the flow load view without building anything.

Flow time trends track how long items are taking from start to finish over recent weeks. This is the equivalent of watching your cycle time on a CFD. If the trend is climbing, something in the process has changed. If it is stable, your process is in control in the SPC sense: it is predictable, even if not fast.

Velocity variance and standard deviation are how GoalPath models forecast uncertainty. Rather than giving you a single-point estimate for when a milestone will finish, GoalPath uses the actual variance in your team's velocity to widen or tighten the forecast range. High variance equals wider range. Consistent delivery equals tighter range. This is statistical process control applied directly to your forecasts. The team with a standard deviation of two points per week gets a tighter date range than the team with a standard deviation of eight, because their process is more in control.

The insight categories these map to in GoalPath Insights are "Predictability & Forecasting" and "Flow & WIP", which is not a coincidence. Those are the same two questions a CFD answers.

When variance is signal vs noise in practice

Here is the practical heuristic. If your velocity drops one week and then recovers without any change in the process, that is probably noise. If it drops and stays low, or drops in a way that correlates with a change you can name (a new engineer joined, a large unestimated item landed, a dependency got blocked), that is signal.

GoalPath's forecast range already accounts for your historical variance. If a slowdown stays within the range that the standard deviation predicts, you probably do not need to react. If your current pace is pushing the expected delivery date out beyond the pessimistic scenario, something real has changed and you need to find it.

The meeting that this replaces is the delivery review where someone says "we had a slow week, should we be worried?" GoalPath answers that question with data: here is how this week compares to your normal variance. Is this week outside your control limits? The mechanism is the structured execution data GoalPath collects as teams do their work, used to generate a forecast range grounded in how this team actually delivers, not a generic assumption.

What to check if your flow looks unstable

If you are seeing high variance in GoalPath's forecasts, or if the flow load aging shows multiple items sitting in the same state for a long time, the diagnosis usually points to one of three places:

WIP is too high. Items enter faster than they exit. The CFD equivalent is bands widening. In GoalPath, this shows up as a long aging list with items across multiple milestones. The fix is to stop starting and start finishing.

A stage is blocked. One particular state accumulates items while others flow normally. In a CFD this is a specific band that widens while others stay thin. In GoalPath you can see this in the breakdown of where aged items are sitting. If they are all queued at the same point, that is your bottleneck.

Estimation variance is high. Items marked as "small" take wildly different amounts of time to finish. This inflates velocity variance without telling you anything useful about the process. The fix is not to estimate more precisely. It is to make items more consistently sized.

The honest answer about CFDs

Teams that use CFDs religiously are doing something valuable. Having a visual representation of flow over time makes patterns visible that raw numbers hide.

GoalPath now gives you that visual: a stacked area chart on the velocity analytics page showing item counts per status over time. You can toggle between weekly and daily granularity, filter by milestone, and see exactly where bands widen or the done line goes flat.

But the chart alone is not the point. The questions a CFD answers (is my WIP growing, is my cycle time stable, am I delivering at a consistent rate) are also answered by the flow metrics, forecast variance, and aging views built into GoalPath. You get the chart when you want the pattern. You get the diagnostics when you want the action.

For most teams, the bottleneck was never the absence of a CFD. It was that the relevant data did not surface in the normal workflow until someone had already called a meeting about it. GoalPath puts it in the workflow (the chart, the metrics, and the coaching) so you see it before the meeting gets called.

Further reading

• What Is the Cumulative Flow Diagram? (Businessmap): a solid primer on reading CFDs, including the bottleneck and stagnation patterns
• Aging Work in Kanban (Nave): how work item age connects to cycle time and forecast accuracy
• SPC for DevOps (Airacad): applying statistical control charts to software delivery metrics
• 4 Key Flow Metrics (Scrum.org): the canonical flow metrics framework: WIP, cycle time, throughput, and work item age

Most teams, when asked how productive they are, point to velocity. Points per sprint. PRs merged per week. Story points delivered against the roadmap.

It is not a bad instinct. Those numbers are real. But if you have ever managed a team that was hitting velocity targets and still missing every forecast, or watched a team slow down right before they burned out, you know that throughput alone is a bad summary of what is happening.

In 2021, a group of researchers from Microsoft, GitHub, and the University of Victoria published a paper in ACM Queue called "The SPACE of Developer Productivity." Their core finding was simple: productivity cannot be reduced to a single dimension. They proposed five.

SPACE stands for Satisfaction, Performance, Activity, Collaboration and culture, and Efficiency. No single metric covers more than one of those dimensions. Which means if you are only tracking one thing, you are flying with four instruments missing.

The five dimensions, in plain terms

Satisfaction is whether developers find the work meaningful, whether they feel the tools and process support them, and whether the job is sustainable. It shows up as retention, engagement, and the quality of work people are willing to put in when things get hard.

Performance is outcomes, not outputs. Did the features shipped actually achieve what they were meant to achieve? For a delivery team, it shows up as velocity, forecast accuracy, and change failure rate.

Activity is the volume of work happening. Commits, PRs, items in progress, tasks completed. Activity is easy to measure and easy to misread. High activity alongside low performance usually means something is broken in the flow.

Collaboration and culture is how well information moves across the team, and whether the environment supports people doing their best work. Are blockers surfaced quickly? Do people know what others are working on? Is the team aligned on priorities? This one is almost impossible to measure with tooling alone.

Efficiency is how smoothly work moves from start to done. Cycle time, flow efficiency, the ratio of active work time to total lead time. A team with poor efficiency is one where work starts and then sits, waiting for review, waiting for a decision, waiting for a dependency to resolve.

The paper's recommendation is to measure across at least three dimensions to get a meaningful picture. One or two dimensions creates blind spots you will not see until they become expensive.

Which three GoalPath covers automatically

GoalPath does not cover all five. It is worth being honest about that.

Satisfaction requires asking people. No amount of workflow data tells you whether someone feels burned out or undervalued. That needs a survey, a one-on-one, a manager who is paying attention.

Collaboration and culture, in the sense the SPACE framework means it, is also hard to instrument. You can proxy it, but the real signal comes from observing how the team actually coordinates, what gets missed, where misalignment shows up after the fact.

What GoalPath does cover, and covers without any extra work from the team, is Performance, Activity, and Efficiency.

Performance: velocity and forecasts

Every time a team marks work finished in GoalPath, the system updates its velocity model. Velocity is calculated across the last six weeks. Consistency matters as much as speed. A team that delivers 10 points every week is more predictable than one that swings between 5 and 20, and GoalPath tracks that variance and uses it to widen or narrow the forecast range accordingly.

The forecast tells you the expected completion window for each milestone, updated continuously as work comes in or slips. This replaces the "where are we?" sync, the Friday status email, and the quarterly guess-and-spreadsheet exercise that most teams still run.

Activity: WIP and flow load

GoalPath tracks how many items are in flight across the team at any point, and how that load is distributed across milestones. GoalPath calculates a penalty for each team member based on how many milestones they are personally juggling, not as a punishment, but because the research is clear that context switching reduces effective throughput. The original SPACE paper notes that high activity can actually be a warning sign: more volume sometimes means brute-forcing through bad systems, not genuine capacity.

The WIP view in GoalPath makes this visible. You can see instantly whether the team is focused or scattered. Items sitting in "Started" without movement flag early, before they become a stakeholder conversation about why the milestone is late.

Efficiency: flow efficiency and cycle time

Flow efficiency is the ratio of active work time to total lead time. Most teams sit at 15–25%, meaning three quarters of the time from "work started" to "work done" is waiting, not working. Reviews queued up, decisions pending, dependencies unresolved.

GoalPath tracks cycle time for every item, from when work starts to when it finishes, and surfaces items that are aging in place. This is where the efficiency dimension of SPACE becomes actionable. It is not that the team is slow. It is that something is blocking flow, and the data shows you where.

The replaced ritual

The monthly productivity review. Every engineering organization runs some version of it. Someone pulls together a spreadsheet of commits, PRs, or story points, and the conversation becomes "are we going fast enough?" It is the wrong question, and the data never tells you why the number is what it is.

The SPACE framework reframes the question to: fast and sustainable, or fast and fragile? The three dimensions GoalPath surfaces automatically give you enough of that picture to have a real conversation. Velocity tells you the pace. WIP tells you whether the pace is sustainable. Cycle time tells you where the friction is.

The mechanism is straightforward: GoalPath's guided workflow captures structured execution data as teams work, and that data becomes the report. No one fills in a status update. No one aggregates a spreadsheet. The progress report, the forecast, and the efficiency view are all outputs of the same workflow that was already happening.

What you still need to do yourself

The two dimensions GoalPath cannot measure for you are the two that require conversation.

Satisfaction shows up in attrition and in the quality of work before it shows up in any dashboard. The best signal is a regular one-on-one where you ask how it actually feels to be on the team right now. Not "are you blocked?" but "is the work sustainable? Do you feel like what you're building matters?"

Collaboration and culture shows up in the quality of handoffs and in how quickly the team surfaces misalignment. The best proxy is whether blockers are raised early or raised after they have already slipped a milestone. If your team tends to surface problems late, that is a collaboration signal, not a velocity one.

These two dimensions require you to show up as a manager, not just as someone who reads dashboards.

A more complete picture

The SPACE framework is not a checklist to fill out. It is a reminder that any single number you use to describe team productivity is, at best, a rough approximation.

GoalPath covers three of the five dimensions automatically, from the same workflow data the team is generating anyway. For the other two, there is no substitute for asking.

That is a more honest way to think about productivity than velocity alone ever was.

Further reading

• The SPACE of Developer Productivity (ACM Queue, 2021): the original paper by Forsgren et al., free to read
• What is the SPACE framework and when should you use it? (GetDX): practical breakdown of which metrics fit each dimension
• DORA 2025 Report: how AI tools are changing throughput metrics while leaving delivery stability flat
• Activity ≠ progress: how WIP overload makes teams look productive while delivery stalls

When delivery slows down, the instinct is to do more of everything. Add a developer. Run more standups. Break tickets smaller. Push the team harder. If some is good, more is better.

Eliyahu Goldratt spent a career arguing this was exactly backwards. His book The Goal, published in 1984 and set in a factory, makes one point over and over: a system's throughput is limited by exactly one constraint at a time. Every resource that isn't the constraint has surplus capacity. Speeding it up doesn't make the system faster. It just builds up a pile of work in front of the actual bottleneck.

Software teams rediscover this constantly. They invest in faster CI pipelines, then the backlog sits in code review for a week. They hire a second QA engineer, but the bottleneck moves to staging environment availability. The constraint shifts. The improvement doesn't stick. The team is baffled.

Goldratt called this the Five Focusing Steps: identify the constraint, exploit it, subordinate everything else to it, elevate it if you have to, then repeat because the constraint will move. You don't need a factory floor to apply this. You need to know where work gets stuck.

What a constraint looks like in software

In a physical factory, the bottleneck is obvious. One machine runs at 70% capacity while every other machine is waiting. You can see the queue building on the floor.

Software work is invisible. Items sit in "In Progress" or "In Review" and nobody has a clear view of how long they've been there, which person is overloaded, or whether the team is blocked on decisions more than execution.

The most common constraints in software delivery aren't what teams think they are. Code review is a frequent one. Not because developers are slow to review, but because too many items are open at once and reviews happen in batches rather than continuously. Staging environment contention is another. So is product approval, architecture sign-off, or the one senior engineer who's a required reviewer on every security-sensitive change.

Research on software team performance consistently shows that teams with the highest throughput aren't the ones working the hardest. They're the ones with the shortest queues and the fewest handoffs. Recent DORA research found that organizations investing in AI coding tools without first addressing their deployment or review bottlenecks often made things worse: more code was generated, but it piled up in the same constrained review and integration stages, making lead times longer, not shorter.

Why optimizing non-bottlenecks is waste

This is the part that feels counterintuitive until you've seen it a few times.

Imagine a team where the bottleneck is code review. Developers are fast. Testing is fast. Deployment is automated. But there are only two senior engineers who do meaningful reviews, and they're also the ones running the architecture discussions, the oncall rotation, and the stakeholder demos.

You decide to hire two more developers. Now there are more pull requests, waiting for the same two reviewers. Lead time goes up, not down. Throughput stays flat. The two new developers are busy, but the system isn't faster.

Goldratt called this "local optimization." You made one part of the system more efficient. But the system's output is determined by its slowest stage, not by the average of all stages.

Exploiting the constraint, before elevating it, means squeezing more out of what you already have. If code review is the bottleneck, you don't immediately hire another senior engineer. You first ask: are reviews waiting because of process, not capacity? Could you review smaller diffs? Could you batch reviews into dedicated morning slots and stop context-switching reviewers? Could you reduce the number of things in progress so fewer reviews are outstanding at once?

Subordinating the rest of the system to the constraint means the developers should probably slow down their output rate to match what the reviewers can absorb. That's also counterintuitive. But starting new work when there's a queue in front of reviewers just grows the queue. It doesn't help.

The Friday status call that hides the bottleneck

In most teams, the ritual that's supposed to surface this information is the weekly status call or the sprint retrospective. "How are we doing? Any blockers? What's slow?"

The problem is that people report on what they feel, not on where the work actually is. A developer who is fast but feeding into a stuck review queue feels productive. A reviewer who is overloaded but managing to work through the queue heroically doesn't want to say "I'm the bottleneck." The retrospective produces observations like "we need better communication" rather than "eight items have been in review for over two weeks."

That's what flow data is for.

Where GoalPath makes the constraint visible

GoalPath's Velocity Analytics page has a section called Flow Metrics. It runs four numbers that, read together, tell you a lot about where your constraint probably is.

The first is Flow Time: median lead time (from creation to done), median cycle time (from started to done), and wait time (how long items sit before anyone touches them). If lead time is long but cycle time is short, items are spending most of their life waiting, either waiting to be started or sitting in review. That gap is the signal.

The second is Flow Efficiency: the ratio of active time to total lead time. Industry benchmarks put the average software team somewhere between 15% and 25%. Below 15% means three-quarters or more of an item's life is waiting, not being worked on. That's not a people problem. That's a queue problem, which is a constraint problem.

The third is Flow Load, which shows total items in progress and breaks them into aging buckets: fresh (under 3 days), normal (up to 7 days), aging (up to 14 days), stale (up to 30 days), and stuck (over 30 days). Stuck items are the most direct signal. An item that's been "in progress" for over a month isn't in progress. It's blocked on something, and that something is probably your constraint. If you have five stuck items and they all belong to the same person, you've found the overloaded node.

Flow Load also shows WIP per person. If one team member has seven items in flight while others have one or two, the work isn't actually flowing to the constraint. It's piling up with one person. That's a distribution problem, but the fix often reveals the constraint: that person is overloaded because they're the only one who can do a specific thing.

The fourth metric, Flow Distribution, breaks down what type of work is flowing (features, bugs, tasks). A team where bugs are crowding out features is often one where quality issues are the hidden constraint: defects from earlier work are consuming the capacity that should be going to new delivery.

A practical way to find your constraint

Open the Flow Metrics view and look at the stuck count in Flow Load. If stuck is more than zero, start there. Click through to the items themselves and ask: why is this item still in progress? Who last touched it? What's it waiting for?

Often you'll find a pattern. All the stuck items are waiting for a specific person. Or they're all in the same milestone. Or they all require a specific environment that isn't available. That's your constraint.

Then look at Flow Efficiency. If it's below 15%, the team is spending most of its time waiting rather than doing. The question is: waiting on what? Cross-reference with Flow Load per person to see if the wait is concentrated around a specific bottleneck.

If wait time is high but no single person stands out, look at the Velocity Analytics section for coordination impact. GoalPath calculates a multitasking penalty when the team is spread across many active milestones simultaneously. A 30% velocity reduction from coordination overhead means the constraint might not be a person or a stage. It might be attention, spread too thin across too many parallel tracks of work.

What to do once you find it

The constraint dictates the system's throughput. Your job is first to exploit it: get more out of it without spending more. Then subordinate: don't start work faster than the constraint can absorb it.

If code review is the constraint, that means:

• Keep the review queue short, even if it means developers start fewer things
• Clear the oldest reviews first, not the newest (FIFO, not LIFO)
• Make the reviewer's time protected and uninterrupted
• Reduce diff sizes so reviews take less time per item

If architecture sign-off is the constraint, document the decision patterns so not every PR needs senior involvement. Pull the architect upstream to the design stage, not downstream to the review stage.

If staging availability is the constraint, shift work-in-progress limits upstream so fewer things compete for staging slots.

Goldratt's last step, repeat, is the one teams most often skip. When you break one constraint, a new one emerges somewhere else in the system. That's expected and fine. It means the system is improving. The point isn't to find a permanent bottleneck. It's to keep finding the current one and focusing effort there, instead of spreading it everywhere.

The ritual this replaces

Most teams replace "where are we?" with a weekly status call where people report on how busy they feel. GoalPath replaces that call with data. Flow metrics are calculated from actual item movement: when things were started, how long they sat, whether they're still moving. The weekly progress report GoalPath generates draws on the same underlying data.

The mechanism is straightforward: when your team moves work through GoalPath's guided workflow, every status transition is recorded. That data aggregates into the flow metrics, which are recalculated weekly. Instead of asking "is anyone blocked?" in a meeting, you look at the stuck count and the per-person WIP. The constraint is visible before it becomes a crisis.

Further reading

• Goldratt, E.M.: The Goal: A Process of Ongoing Improvement (Theory of Constraints Institute overview)
• IEEE Xplore: Bottleneck Identification in Software Development Processes: A Proposal Based on the Principles of the Theory of Constraints
• DORA: State of DevOps Report 2024, especially the finding on AI amplifying existing constraints
• Planview: Flow Metrics Business Leader Guide

If you have been around engineering teams for a while, you've probably watched this play out: leadership asks how the team is performing, and someone opens a spreadsheet. They count PRs merged this sprint, maybe check Jira for cycle time, pull GitHub stats for deployment count. An hour later, there's a slide deck with five different numbers that don't quite agree.

DORA metrics exist to fix that. The four keys give teams a shared vocabulary for engineering performance. But most DORA explainers stop there: "here's what to measure, go instrument your pipelines." The part that's harder to find is what the numbers actually mean day-to-day, what good looks like, and how to get the signal without running a separate measurement program.

If you're already running work through GoalPath, a lot of that signal is already there. This post maps the four keys to what GoalPath tracks, shows where the gaps are, and explains what Elite performance actually requires.

The four keys, plainly

DORA (DevOps Research and Assessment) identified four metrics that consistently predict both software delivery performance and organizational outcomes. The research has been running since 2014, with annual State of DevOps reports from Google Cloud. The four are:

Lead time for changes. How long does it take from code committed to code running in production? This includes review, testing, merge, and deploy. Elite teams get under one day. Most teams take between one day and one week. The long tail (one to six months) is more common than people expect.

Deployment frequency. How often do you ship to production? Elite teams deploy on demand, multiple times per day. Medium performers deploy somewhere between once per week and once per month. Low performers deploy once per month or less. The gap between elite and low is enormous: 182 times more deployments per year.

Change failure rate. What percentage of changes cause a production incident or require a rollback? Elite teams stay under 15%. The DORA data shows the largest cluster of teams sitting at 8-16%, which sounds manageable until you realize what it means for cumulative incident load over a year.

Mean time to restore. When something does go wrong, how fast do you recover? Elite performers restore in under an hour. More than half of teams in the 2024 report took between one day and one week, which means customers are affected for days, not minutes.

The 2025 DORA report moved away from the four-tier classification (low/medium/high/elite) toward seven team archetypes, which reflects how much variance exists in real teams. But the core measurements haven't changed, and the performance gaps between strong and weak teams are as large as ever.

Where DORA runs into product teams

DORA was designed for teams with continuous deployment pipelines. Every metric assumes "deploys to production" as the unit of work. That works well for API services and web apps with mature CI/CD. It works less well for teams shipping iOS apps on a two-week App Store review cycle, or SaaS products where "deploy" means "merge to main and wait for a release train."

Product teams also rarely have the tooling to instrument these metrics accurately. Lead time for changes requires correlating a commit timestamp to a production deploy timestamp. Change failure rate requires tagging incidents to specific deployments. These are engineering-level metrics that require investment to collect cleanly.

That's not a reason to ignore DORA. It's a reason to understand what you can measure with the tools you already have, and where to approximate.

How GoalPath maps to the four keys

GoalPath tracks work at the item level, from when an item is created and started through to when it's finished and delivered. That workflow captures most of what DORA wants to know, in a form product teams can actually use.

Lead time for changes → Flow Time

GoalPath's Flow Time metric shows you two numbers: lead time (from item creation to delivery) and cycle time (from when work actually started to delivery). DORA's "lead time for changes" is closest to cycle time (the active development window). But lead time is what your stakeholders feel.

The Insights page shows both, plus wait time (the gap between creation and when anyone picked it up). A team with cycle time of 2 days and wait time of 12 days isn't a fast team. The work is just waiting to be started.

Elite DORA teams get lead time under one day for a code change. For product feature work, "under one day" is usually not realistic. Features take longer than hotfixes. The useful comparison is your own trend over time. If your median flow time is improving month over month, you're moving toward elite behaviors even if the absolute number is higher.

Deployment frequency → Velocity and throughput

DORA's deployment frequency measures how often you ship to production. GoalPath's velocity measures how many story points your team completes per work week. They're related but not identical.

A team with high deployment frequency and low velocity is shipping frequently but not much. A team with high velocity and low deployment frequency is building fast but releasing slowly, which often means large, risky batches.

The useful signal from GoalPath's velocity chart is throughput: how many items are you finishing each week, and is that trend stable or erratic? Erratic throughput (big weeks followed by dead weeks) often signals the same problems that hurt deployment frequency: large items, review queues, dependencies waiting for other teams.

If your throughput is consistent week over week, you're exhibiting one of the core behaviors of high-frequency deployers: steady, predictable flow instead of batch-and-release.

Change failure rate → Bug ratio in Flow Distribution

This is the trickiest mapping. DORA's change failure rate is specifically about production incidents caused by a deploy. GoalPath doesn't monitor your production environment. It manages your planned work.

What GoalPath does track is Flow Distribution: the split of completed items across Features, Bugs, and Tasks. If your team is completing 40% Bugs in a given period, that's a signal. You're spending nearly half your capacity on things that were already shipped and broke.

High bug ratio in Flow Distribution is a leading indicator of high change failure rate. Teams that ship quality problems generate rework. That rework shows up as the next sprint's bug list before it ever shows up in a DORA dashboard.

Healthy teams in the DORA data tend to have low rework ratios. In Flow Distribution terms, that usually means bugs staying below 15-20% of completed work. It's not a hard benchmark (a team doing active maintenance on a legacy codebase will skew higher), but the trend matters. If bugs as a percentage of completed work are increasing quarter over quarter, your change failure rate is probably climbing too.

Mean time to restore → Item aging in Flow Load

DORA's MTTR measures how fast you recover from a production incident. GoalPath doesn't track incidents, but it does track aging WIP items and how long they've been in progress.

Flow Load shows you items currently in progress and how many are stale or stuck. A stuck item is one that has been in progress for more than 30 days. Stuck or stale items are often held up by external dependencies, unclear requirements, or decisions waiting on stakeholders.

The analogy to MTTR isn't perfect. Stuck feature work isn't the same as a production outage. But the capability that drives fast MTTR is the same capability that clears stuck or stale items fast: clear ownership, fast decision-making, and a culture where problems surface quickly instead of aging silently.

Teams that let items sit stuck for weeks are usually the same teams where incidents last days. The organizational habits that create long MTTR create long item aging. Watching Flow Load gives you early warning before the incident queue tells you about it.

What Elite actually requires

The DORA data shows that 19% of teams reach elite performance on the four keys. What makes the difference is not tooling. It's a set of organizational practices that elite teams have and lower performers don't.

Small batches. Elite teams ship small changes frequently. They don't accumulate two weeks of work into a large release. Small batches mean smaller blast radius when something goes wrong, faster cycle times, and easier rollbacks.

Deployment confidence. Teams that deploy multiple times per day have invested in automated testing and deployment pipelines. They don't deploy manually. They don't have a "release manager" who coordinates deploys. The pipeline does it.

Fast feedback loops. Elite teams know within minutes if a deploy caused a problem. Staging environments don't cut it. You need production observability.

Decision speed. This is the one GoalPath can help with directly. A common source of long lead times and stuck items is not technical complexity. It's slow decisions. Whose sign-off is needed? Who reviews this change? Who decides if this is good enough to ship? Teams where those answers are unclear will struggle to hit elite performance regardless of their deployment infrastructure.

The ritual GoalPath replaces

The typical DORA measurement program looks like this: someone in engineering leadership decides the team needs metrics, they instrument a data pipeline, pull data from GitHub and Jira, build a dashboard in Grafana or Tableau, and run a quarterly review.

Three months later, no one is looking at the dashboard. The quarterly review doesn't change anyone's behavior. The data is accurate but not actionable.

GoalPath doesn't replace DORA instrumentation for teams that need it. If you have dedicated SREs and are deploying fifty times a day, you need proper observability tooling. But for product teams of five to twenty engineers who just want to understand whether their delivery health is improving or degrading, GoalPath's flow metrics page gives you the signal you need from work your team is already doing.

No additional instrumentation. No separate dashboard. No quarterly review cycle. The metrics update as items move through your workflow, and the weekly progress report surfaces the trends automatically.

If something is wrong (flow time is climbing, bug ratio is up, five items have been stuck for three weeks), the Insights page shows it. You can act on it in this week's planning instead of discovering it in a quarterly report.

Further reading

• DORA's official four keys guide: dora.dev/guides/dora-metrics-four-keys
• 2025 DORA report (AI's impact on delivery metrics): dora.dev/research/2025/dora-report
• Octopus Deploy's breakdown of the 2024 performance clusters: octopus.com/devops/metrics/dora-metrics
• RDEL newsletter on 2025 DORA benchmarks: rdel.substack.com/p/rdel-115-what-are-the-2025-benchmarks

GoalPath has three very different types of users. What the tech lead needs to look at every morning is completely different from what the CEO needs to look at on Thursday before the board call. So instead of one generic "getting started" guide, here are three short ones.

A quick note on role names: in GoalPath, a tech lead is typically a ProjectLeader or Collaborator. A product owner is usually the project Owner. Stakeholders and Viewers both have read-focused access, but with different levels of participation. Stakeholders can vote in alignment meetings, Viewers cannot.

For the Tech Lead

What GoalPath does for you: It replaces the "where are we on this?" Slack messages and the Monday status meeting with a dashboard you can check in 60 seconds, and a weekly report that writes itself.

You are the person who actually knows what is happening. You just spend a lot of time translating it for everyone else. That is the problem GoalPath fixes.

What to look at every day

Open the project dashboard. You want to see two things:

First, how many items are currently in progress. If the WIP count is climbing (people starting new things before finishing old ones), that is the first sign a milestone is going to slip. You do not need to wait for a retrospective to notice it.

Second, glance at the milestone forecast. GoalPath calculates this from your actual delivery velocity over the past six weeks. If something shifted since yesterday, you will see it there. The forecast panel shows you the numbers. If the expected date moved, the weekly progress report will include an explanation of why.

What to look at in your first week

Velocity Analytics page. This is accessible via the sidebar. You will see your team's rolling average story points per work-week, with a variance band. Flow metrics also appear on the Insights page. Do not try to optimize it on day one. Just look at it. Is velocity consistent? Wildly variable? That tells you more about your process than any sprint review.

The roadmap. GoalPath shows milestones as a dependency graph, not a Gantt. You can see the critical path: which milestones are blocking what. If you are three milestones deep into a chain and the first one has a bloated WIP count, you now know your actual problem.

Progress report preview. By the following Sunday (the cron runs Sunday nights), a draft progress report will be generated automatically from what your team shipped. Read it. If something is wrong or missing, that tells you something about how items are being structured or closed out. Once you trust the drafts, reviewing them before sending takes about two minutes.

The thing most tech leads miss

GoalPath uses guided standup and alignment meetings. You do not need to facilitate these from scratch. The interface walks through the stages: what shipped, what's blocked, anything unplanned that crept in. The blockers surface automatically. You do not need to ask. Note that the guided standup is available to team members with edit access: Owners, ProjectLeaders, and Collaborators.

If you are spending more than fifteen minutes per day in status-related conversations, something is not set up right. The tool is supposed to absorb that.

For the Product Owner

What GoalPath does for you: It turns your roadmap from a Google Sheet that is wrong by Tuesday into a live dependency map that updates itself. And it gives you an automatic progress report every week that you can share with leadership without spending your Friday afternoon writing it.

What to look at in your first week

Start with the roadmap view. Add your milestones. Connect the dependencies. GoalPath will show you the critical path automatically: which things have to happen before which other things. This is the conversation you normally have in a planning meeting, except now it is just visible.

The alignment meeting flow is where GoalPath earns its keep. Alignment meetings in GoalPath have six structured stages: progress snapshot, Flow Health & Escalation, business value voting, roadmap brainstorming, roadmap update, and a summary. You do not need to design the meeting format. The tool runs it. What you get out is an ordered priority list that the whole group participated in creating, which means you spend less time defending decisions afterwards.

Business value voting is the part worth highlighting. Instead of whoever is loudest in the room deciding what comes next, GoalPath collects votes from your stakeholders using a structured framework: Impact/Effort, RICE, MoSCoW, or a configurable weighted scoring framework. It normalizes the scores to a 1–100 scale. All of a sudden you can sort the roadmap by business value instead of by who pinged you last on Slack.

The replaced ritual to notice

You will have a Friday or Monday ritual right now: either writing a status email, or running a sync where someone summarizes what happened last week. Both of these go away. GoalPath generates the progress report draft from execution data (what shipped, what is blocked, how forecasts changed) every week. You review it, make any edits you want, and send it. The whole thing takes a few minutes.

Your stakeholders stop asking "where are we?" because they already know.

For alignment meetings: stop prepping slides

The classic product owner move is to spend two hours before a planning meeting building a slides deck to show the roadmap. You do not need to do this. The GoalPath roadmap is the meeting. Pull it up, work through the stages, done.

For the Stakeholder or Viewer

GoalPath distinguishes between two read-focused roles: Stakeholders participate in alignment meetings, including voting on business value priorities. Viewers can observe alignment meetings but do not vote. Both receive progress reports and can see the project roadmap and forecasts.

What GoalPath does for you: It means you stop having to ask. You get a plain-English progress update every week that tells you what shipped, what is behind, and when things are expected to be done, without needing to understand what "velocity" or "story points" means.

GoalPath is designed so you should not need to understand lean delivery methodology to know what is happening. The team's work gets turned into something readable. That is the whole point.

What to look at in your first week

The weekly progress report. This is your primary artifact. It shows up automatically, generated from actual work data, not from what someone remembered to write down. The AI-generated report typically covers what shipped, what is blocked, forecast changes (if the expected delivery date moved, it says so and by how much), and items that need attention or a decision from you.

That last section is the important one. GoalPath surfaces items that are waiting on a stakeholder decision. You do not need to dig through a Jira board to find them. They are right there.

Understanding the forecast

GoalPath shows three forecast scenarios for each milestone: Optimistic, Most Likely, and Pessimistic. These are calculated from actual delivery velocity, not from someone's guess in a planning meeting.

If the expected date moves, you will see it in the progress report. The forecast panel shows the updated numbers; the weekly progress report is where you will find an explanation of what changed and why. The forecast is based on what the team has actually been delivering, so when it moves, it usually means something real happened: someone got blocked, a dependency shifted, scope changed.

You do not need to interrogate anyone about timelines. The number is in the forecast panel. If you want to understand why it changed, the explanation is in that week's progress report.

When to actually open GoalPath

Most stakeholders do not need to check GoalPath every day. Here is a simple pattern:

• Read the weekly progress report when it arrives (Monday morning typically). Two minutes.
• If there is an item flagged as needing your decision, handle it before end of day.
• Before a board meeting or investor call, open the project and look at the forecast panel. You will have everything you need.

That is it. You do not need to understand the velocity chart or the roadmap dependency view. Those are for the tech lead and product owner. Your interface is the progress report.

Starting as a team

One thing that helps all three roles is doing the first alignment meeting together in week one. GoalPath walks you through it. The product owner drives, the tech lead provides technical context, stakeholders vote on business value. Everyone leaves knowing the priority order, and they all participated in setting it.

That single meeting often replaces three or four recurring syncs that have been happening on autopilot.

After that, the rhythm is: team works in GoalPath, progress report generates itself Sunday night, everyone reads it Monday morning, nobody needs to ask "where are we?"

That is the goal. Not perfect process. Just shared reality, automatically.

Further reading

• Understanding velocity metrics in GoalPath: how the forecasting math works
• When everything is Priority 1, teams default to the loudest work: why structured prioritization beats gut feel
• Too many things in flight: WIP monitoring and what the tech lead should watch for
• DORA 2025 report on team performance: https://dora.dev/research/2025/dora-report/

So you say "end of the quarter" and hope for the best.

Most teams I've talked to have been doing some version of this for years. Not because they're dishonest, but because the tooling trained them to think in single dates. You open your project management tool, there's a due date field, you put a date in it. Forecast delivered.

The problem is that a single date is not a forecast. It's a guess dressed up as a commitment.

What actually drives delivery time

Before getting into what the numbers mean, it's worth being precise about what determines when something ships.

The short version: remaining work divided by the rate at which the team completes work. That's it. The math is not complicated.

The hard part is that both inputs have variance. Remaining work changes. Scope creep is not an exception, it's the norm on most software projects. And team velocity fluctuates week to week. Some weeks the team ships 12 points, some weeks they ship 6. Bugs, sick days, an unexpected architecture decision, a dependency that wasn't ready. Real teams are not machines that run at constant throughput.

When you divide a changing numerator by a variable denominator, you don't get a date. You get a distribution. Some outcomes cluster around a central value, some skew later, occasionally things go faster than expected. Pretending otherwise doesn't make the uncertainty go away. It just hides it until the date passes.

Research on the planning fallacy (Kahneman & Tversky) confirms that humans systematically underestimate how long things will take, even when they have prior experience with similar tasks. For software projects specifically, research suggests underestimates often run 40–60%. This is not a failure of individual competence. It's how human cognition works. You focus on the task ahead, not on everything that went sideways last time.

A good forecast system doesn't fight human nature by asking people to estimate better. It uses actual delivery history to build the range automatically.

The three scenarios GoalPath shows you

When you open the forecast panel on a milestone in GoalPath, you see three completion dates, not one. Optimistic, Most Likely, and Pessimistic. Each one represents a different assumption about how the remaining work will go.

Optimistic is not "best case if everything goes perfectly." It's best case based on the upper end of your actual velocity history. GoalPath calculates this using your team's velocity at the upper range of its recent performance: the kind of output you've actually hit in good weeks, not a projection of what you could theoretically do. It is an achievable outcome, not a fantasy.

Most Likely is the central estimate, built from your average (effective) velocity adjusted for real-world factors: how many milestones the team is running in parallel (multitasking reduces effective velocity), the historical rate of scope additions to this type of work, and how many items in the milestone still lack estimates. This is the number you'd bet on if you had to pick one.

Pessimistic is not "what if everything goes wrong." It's what happens when the team runs at the lower end of its demonstrated velocity, accounting for the same adjustment factors. A realistic bad-week scenario, not a catastrophe.

The width of the range tells you something important: how predictable this milestone is. A forecast that shows Optimistic on March 12 and Pessimistic on March 13 means the remaining work is small and well-understood. A forecast showing March 12 and April 28 means there's real uncertainty: too many unestimated items, high velocity variance, or both. The range is not a bug in the display. It's the most useful information in it.

GoalPath shows you the calculation behind these numbers if you want to dig in. Click "Calculation Details" and you can see the effective velocity (post-penalty), the standard deviation, the multitasking penalty if one applies, the reactive planning buffer derived from your historical scope additions, and the exact formula used. This is not magic. It's arithmetic applied consistently to your actual delivery data.

The delivery probability lines in your item list

Inside a milestone's item list, you'll notice thin colored horizontal lines appearing between items. These are delivery probability lines, and they're the most useful tool in GoalPath for having scope conversations.

The concept is straightforward. GoalPath takes your three velocity scenarios and asks: if the team works through this list in priority order, at optimistic/probable/pessimistic velocity, which item will be the last one delivered by the target week?

The green line is Best Case. Items above it will likely ship by the optimistic date.

The amber line is Probable. Items above it will likely ship if the team performs at its expected rate.

The red line is Worst Case. Items above it will likely ship even if things go slower than usual.

Items that fall below the red line have a meaningful probability of not shipping in the current cycle at all.

This changes the conversation with stakeholders. Instead of "we think we'll ship all of this," you can point to the screen and say: "these six items are above the amber line, which means they'll ship on the expected scenario. These three are between amber and red, which means they'll ship if things go reasonably well but might slip. These two below the red line are uncertain and we should talk about whether to cut them or push the timeline."

That conversation takes about two minutes. The alternative, where you guess at a date and then explain a slip two weeks before delivery, takes much longer and damages trust in a way that's hard to recover from.

What confidence level means

The confidence badge in the forecast panel (High / Medium / Low) reflects how variable your team's velocity has been over the measurement window. It tells you how much to trust the forecast range. It doesn't add a separate buffer on top of it.

High confidence means velocity has been consistent: the standard deviation is low relative to the average (under 50%). The gap between optimistic and pessimistic dates will be narrow, and the range is fairly reliable.

Medium confidence means moderate fluctuation. Velocity variance is in the 50–70% range. You'll see a wider spread between the three scenarios, and there's more room for surprise in either direction.

Low confidence means high variance, or that GoalPath fell back to global or historical velocity data instead of team-specific data. When the system doesn't have enough dedicated team velocity (fewer than 5 recent completed items from a dedicated team), it falls back to project-wide or historical averages, which caps confidence at Medium or Low regardless of variance. The uncertainty factors in the Calculation Details panel will tell you exactly why.

When you see a low-confidence forecast, the answer is not to distrust GoalPath. The answer is to ask why the variance is high. Usually it's one of two things: items in the milestone lack estimates (easy fix: add them), or the team is spread too thin across parallel work (harder fix, but worth addressing). The confidence badge is a diagnostic, not just a label.

How to use this in stakeholder conversations

The ritual GoalPath replaces here is the "when will this ship?" conversation where you improvise a date, stakeholders write it down, and everyone moves on hoping for the best. That ritual generates false precision and erodes trust when reality doesn't match the improvised date.

The replacement is not more complex. Pull up the milestone forecast panel or the item list and walk through the three scenarios together. It takes about two minutes. Something like:

"Our expected delivery is [Most Likely date], assuming normal velocity. Best case it could be as early as [Optimistic date]. If we hit the kind of delays we sometimes see, such as scope creep or a tricky dependency, it might push to [Pessimistic date]. The high-priority items are expected to ship even in the pessimistic scenario. These lower-priority ones are at risk if things go slowly. Do you want to talk about scope, or should we plan around the pessimistic date?"

Notice what this does: it replaces "we'll ship on X" with "here's the range and here's what determines where we land." It invites stakeholders into a trade-off conversation rather than a date negotiation. It makes scope the variable, not your credibility.

Most stakeholders respond well to this once you do it a few times. The initial discomfort ("why can't you just give me a date?") is mostly habit. When they see that the range comes from real data and that the tool updates automatically as the team delivers, the trust actually goes up, not down.

The key is to be consistent. Use the range every time. Don't give single dates in Slack and then pull out the range only when things are going badly. If the range is your communication standard from the beginning, it becomes the shared reality the team and stakeholders work from.

When forecasts should change your plan, not your date

One thing teams sometimes miss: GoalPath recalculates forecasts whenever something significant changes. Items completed, new items added, velocity changes over the measurement window. The forecast is not set at the start of a milestone and then compared to reality at the end. It's a live reading of where you stand.

If you check the forecast today and it says the pessimistic date is after a commitment you've made to a customer, that's not a forecast failure. That's the forecast working exactly as intended. Not knowing is worse.

The right response to a forecast that shows a date you don't like is not to question the forecast. It's to look at the item list, find what's above and below the probability lines, and decide whether to cut scope, add capacity, or have a timeline conversation now rather than in three weeks when there's no room to maneuver.

The math is not the hard part

I want to be honest about where this actually gets difficult. It's not the math. GoalPath handles the math. The hard part is the organizational habit change.

Teams that have been doing date-picking for years will initially feel that probability bands are evasive, even when they're more honest. Some stakeholders will push back. Some PMs will feel exposed when the range is wide because it makes visible the uncertainty they were previously hiding with a single number.

The discomfort passes. What doesn't pass is the slow erosion of credibility from repeatedly promising dates you can't keep. Three-point forecasts, used consistently, build a different relationship with stakeholders over time. One where they trust the numbers because the numbers have been right about the range, even when they weren't right about the single date.

GoalPath is opinionated about this. There's no single-date forecast, no due date field you fill in manually. The forecast comes from the data, not from what you think will make a stakeholder happy this week. That's a choice, and it reflects a belief that honest uncertainty is more useful than false precision.

A range is not a hedge. It's the most accurate thing you can say.

Further reading

• Using Monte Carlo Simulations to Predict Delivery Timelines: Agile Seekers
• Forecasting software project completion dates through Monte Carlo simulation: Towards Data Science
• Probabilistic forecasting in agile: Agile Digest
• Planning fallacy: Wikipedia (good summary of the research lineage from Kahneman/Tversky forward)

You merge a PR on Friday afternoon. Monday morning, someone in the team chat asks "did the auth redirect fix go out last week?" You scroll through the merged PRs, click into the right one, copy the commit subject into the GoalPath item comment, paste a link, hit send. Five minutes gone, twice a week, every developer on the team.

This is the kind of small ritual that nobody notices is expensive until you add it up. Two minutes here, three minutes there. Multiply by every item, every week, every team. The gap between "the work shipped" and "the activity timeline knows the work shipped" is where status updates go to die.

GoalPath has had a GitHub commit linking integration since April. Tag a commit with #GP-47 (or #GP47, both work, case insensitive) and the integration files it under that item's activity timeline within seconds. Branch names like feature/GP-47-auth-redirect work too. PR titles work too. The plumbing has been there for weeks.

But the link rate has been embarrassingly low. The reason was simple: the AI coding assistants writing most of those commits had no idea the convention existed.

This week we shipped four small updates that close that gap. None of them changed the parser or the integration itself. All of them changed where the convention is documented so AI assistants actually see it.

What changed

Four things, none of them dramatic on their own. Together they make the AI assistant a useful collaborator instead of a forgetful one.

The CLI gained enum schemas on its MCP tools. When your AI assistant calls a GoalPath tool through the Model Context Protocol, it now gets a clear, immediate error if it tries to set an item to "Done" instead of "Finished", or types "blocked" instead of "Blocked". Before, the call sailed through validation and failed somewhere downstream with a less actionable message. The valid values are now part of the schema the AI sees, so most typos never happen in the first place.

The CLI surfaces the item's short number in MCP responses. When the AI creates an item, lists items, or searches items, the response now includes the #GP-N short number directly. Before, the AI had to call get_item after creating something just to read the number. One less round trip, and the number is right there next to the title where the AI is already looking.

The goalpath mcp init command grew an instruction file flow. Run goalpath mcp init in any project and it now detects whether you have a CLAUDE.md, AGENTS.md, .cursorrules, or .github/copilot-instructions.md. If you do, it offers to append a small section explaining the #GP-N commit tagging convention. The block is wrapped in HTML comment markers so re-running the command updates it in place. No duplication, no clobbering your content.

The skills plugin got a version bump. The goalpath-skills plugin had been teaching the convention since April, but the version field never moved past 1.0.0. The plugin loader caches by version, so installed copies never refreshed. Bumping to 1.0.1 forces every installed copy to pull the current content the next time the user reinstalls. A small fix with outsized consequences for everyone running the skills today.

How to update

If you are running the GoalPath CLI locally as your MCP server (goalpath mcp serve is in your .mcp.json), pull the latest:

npm install -g @goalpath/cli@latest

The new version is 1.1.0. Restart your AI assistant after installing so the tool schemas are reloaded.

For the skills plugin in Claude Code:

/plugin update goalpath-skills

Or reinstall it from the marketplace. The version you want is 1.0.1 or newer.

If you already have a project with an instruction file (CLAUDE.md, AGENTS.md, .cursorrules, or .github/copilot-instructions.md), this is a good time to run:

cd /path/to/your/project
goalpath mcp init

It will detect the file and offer to append the #GP-N section. Pick yes, commit the change, and every developer (and every AI assistant) on the team gets the convention for free.

Why this matters

The deeper point is not really about commit linking. It is about what an AI coding assistant needs to be a useful collaborator on a real product team.

Without context, an AI is a confident stranger. It writes code that compiles, but it has no idea which item the code belongs to, which status transitions are valid, or whether the change you just asked for is the highest priority work today. So the human has to be the bridge: paste an item ID into the prompt, copy the AI's output back into the GoalPath comment, manually update the status. The AI is helpful in narrow ways, but the team's process still runs on a parallel track in the human's head.

The MCP server changes that. The AI gets direct, scoped access to GoalPath through proper auth boundaries. It can read what you are working on, write status updates, post comments with PR links, and now tag the commits it writes so the activity timeline reflects what actually shipped. The team's process becomes the AI's process, not the human's.

The skills package the workflow on top of that. /goalpath-discover turns a half-formed idea into a written PRD. /goalpath-plan breaks that PRD into items with estimates. /goalpath-implement ships the entire milestone on a single branch with one PR. /goalpath-work drives a single item from start to finish. /goalpath-status tells you what is on your plate right now and what to pick up next. The slash commands are short, the structure is consistent, and the AI follows the same path every time.

This is the pattern across every GoalPath integration. The Chrome extension captures bugs from the browser. The VS Code extension puts your task list in the editor sidebar. The CLI runs the MCP server locally so your AI assistant has direct access. The link rate today sits around 2.5 percent, and it should climb steadily now that the convention reaches every AI client through the channels they actually read. We will know it is working when "did that ship?" stops appearing in the team chat.

Try it

Update both packages, run goalpath mcp init in your project, and watch your next AI-written commit show up under the right item without anyone copying anything anywhere.

Install the GoalPath CLI | Browse the goalpath-skills plugin | Read the integration docs

Here is a situation that happens in a lot of product teams. It is usually a planning call or a sprint review. Someone asks "how is Milestone B going?" and the honest answer is: slowly. Not because the work is hard, not because the team is lazy, but because the same three people who are supposed to deliver Milestone B are also halfway through Milestone A, triaging bugs in Milestone C, and supporting a customer escalation that technically lives in Milestone D.

The work is real. The effort is real. But the milestones are not moving.

Most teams reach for explanations that are more comfortable. The estimates were off. There was unexpected complexity. We had some unplanned work. All of those things may be true. But underneath them, almost always, is a simpler problem: too many milestones running at the same time, with the same people assigned to all of them.

Gerald Weinberg put numbers on this in Quality Software Management. His table is not uniform: two projects means roughly 20% overhead, three projects means 40% total overhead, and five projects leaves you under 25% effective. Each additional project adds more than the last, because switching cost is not linear. DORA research has consistently found that organizational instability, including shifting priorities, correlates with lower performance and higher burnout. It is the same mechanism, viewed at a team level instead of an individual one.

GoalPath applies penalties derived from Lean research on concurrent work streams. The thresholds are calibrated per person, based on how many milestones each individual is actively working across at once:

• 1 milestone: No penalty. Full velocity.
• 2–3 milestones: 15% penalty. Manageable, but real.
• 4–7 milestones: 30% penalty. Significant throughput loss.
• 8+ milestones: 50% penalty. Half effective capacity gone.

These feed directly into each person's contribution to the forecast. The more milestones a person juggles, the less of their capacity counts toward any single one.

Why teams almost never see this

The problem with context switching is that it is invisible in most tracking tools. Your Jira board shows items moving through columns. Your burndown chart slopes downward. Everyone is busy. Nothing is obviously wrong.

What you do not see is the effective velocity. The number of story points your team could deliver if they were focused, versus what they actually deliver when they are split across five active milestones.

Most teams learn about their multitasking penalty at the end of a quarter, when they look back and realise three milestones they planned to finish are sitting at 60%, 70%, and 80% done. Each one almost there. None of them shipped. The Friday status email goes out, and someone writes "good progress across the board." Good progress. Nothing delivered.

That is what the 15–30% penalty looks like in practice. Not a dramatic crash, just a steady erosion of throughput that never shows up until you zoom out.

What GoalPath sees that your status email cannot

GoalPath tracks which milestones each team member is currently active on. Not historically, right now. It looks at in-progress items, finds which milestones each person is actively working across, and calculates a multitasking penalty for each person based on their concurrent milestone count.

That penalty feeds directly into the forecast.

When you open the Duration Forecast panel on a milestone, you will see a "Velocity Impact" section if GoalPath has detected multitasking. It shows the penalty percentage and labels it clearly: "Team velocity reduced due to parallel work streams." The effective velocity shown in the calculation breakdown is the number the forecast is actually built on, already adjusted downward.

Most forecasting tools (spreadsheets, rough estimates, gut feel) assume the team is fully focused on the milestone being projected. They use the raw velocity, the number from when things were going well. GoalPath uses the effective velocity: what the team can actually produce right now, given the number of tracks they are juggling. The two numbers are often far apart.

The Coordination Impact card

The Velocity Analytics page has a card called "Coordination Impact." It appears only when GoalPath detects a project-wide multitasking penalty, meaning enough team members are spread across enough milestones that it is affecting aggregate throughput.

It shows a single percentage: the share of velocity being lost to coordination overhead. Not a theoretical estimate. A calculation from the current state of the project.

When this number is high, the right question is not "how do we go faster?" It is "what can we stop doing simultaneously?"

The ritual it replaces

Most teams learn about their multitasking problem through a retrospective. Something slipped, someone asks why, a senior engineer explains that they have been pulled in six directions. The team agrees to "be more focused." Two weeks later, the planning meeting adds two more parallel tracks because a stakeholder wanted two things.

The retrospective is the replaced ritual. The value is not in the conversation after the slip. It is in seeing the penalty before the commitment is made.

When you are looking at a milestone forecast in GoalPath and you see the effective velocity is 30% lower than the raw velocity because three of the five people assigned to this milestone are also active on two others, you have the data you need before the planning meeting. Not after the quarter ends.

That is the mechanism: guided workflow produces per-person WIP data across milestones, the velocity service applies empirically derived penalties, and the forecast reflects what will actually be delivered. Not what could be delivered in a world where everyone is fully focused.

When running parallel tracks makes sense

Not all parallel work is waste. There are real situations where multiple milestones should be in flight at the same time:

Different teams, different tracks. If your frontend team is building the UI for Milestone B while your backend team finishes Milestone A's API, that is not multitasking. That is parallel specialization with low switching overhead. GoalPath's team-based velocity calculations handle this correctly, tracking velocity per team rather than blending everyone together.

Dependencies with wait time. If Milestone A is blocked on an external dependency for two weeks, it makes sense to start Milestone B rather than idle. The key is that people are not actively working both at the same time.

Short, unrelated bursts. Incident response, a critical bug, a compliance deadline: sometimes two things genuinely have to happen. These are real, and pretending otherwise just means making promises you cannot keep.

The problem GoalPath is designed to detect is not "two things in flight." It is "six things in flight, with the same core engineers on all of them, and forecasts that do not know it."

A practical check you can do right now

Open your project in GoalPath. Go to Velocity Analytics. If you see a Coordination Impact number above 15%, you have a multitasking problem worth addressing.

Then open the milestone you are most worried about, the one with the nearest deadline or the most stakeholder attention. Expand the "Calculation Details" section in the forecast panel. Look at the raw velocity versus the effective velocity. The gap is the cost of context switching, expressed in points per week.

If the gap is large, you have two options. One is to accept the forecast as-is and negotiate scope or timeline. The other is to reduce active milestones, either by finishing one before starting another, or by moving people off tracks they do not need to be on right now.

GoalPath does not make that decision for you. But it makes the cost visible, in the same place where you are already looking at delivery dates, before you commit to something that the data says you cannot deliver.

That is what most teams are missing. Not the knowledge that context switching is bad. Everyone has heard that. What they are missing is a number, attached to their actual team, for the milestone they are actually planning, visible before the promise is made.

Further reading

• Gerald Weinberg's multitasking overhead table: Coding Horror: The Multi-Tasking Myth
• The 2024 DORA report on organizational stability and productivity: dora.dev/research/2024
• SEI on context switching in DevOps environments: SEI Blog: Addressing the Detrimental Effects of Context Switching with DevOps
• Research on task switching and software development: ResearchGate: Impact of task switching and work interruptions on software development processes

Someone asks when the milestone will ship. You have a feeling. You have a spreadsheet. You have last sprint's velocity and a rough point count. You do the math in your head, add a mental buffer because things always take longer, and give a date.

Three weeks later the date is wrong.

Not wrong because your team stopped working. Wrong because the math was always hiding something, and now that something showed up as an unplanned incident, a scope addition, a dependent milestone that wasn't as done as it looked, or just natural velocity variance that hit in the wrong direction.

Some teams are good at this. They give dates and they land within a week of them, consistently. Most teams are not. The question is what separates them.

What actually drives predictability

There are four signals that show up repeatedly in teams that forecast reliably. None of them are surprising in isolation. What's surprising is how rarely teams measure all four at once.

Consistent velocity. Not high velocity. Consistent. A team that delivers 9-11 points every week is much easier to forecast than one that delivers 5 one week and 18 the next. DORA research and flow framework literature both point to stability as a stronger predictor of on-time delivery than raw throughput. When velocity swings wildly, any forecast built on the average is likely to miss. The question to ask is not "what's our average velocity?" but "what's the variance around that average?" High variance is the forecast killer.

Low WIP variance. Teams that limit work in progress tightly have two advantages. First, individual items move faster because there's less multitasking tax. Second, and more relevant to forecasting, the number of items in flight stays predictable. When WIP is high and variable, you get unpredictable queue buildup. Little's Law makes this precise: lead time equals WIP divided by throughput. Double the WIP without increasing throughput and you've doubled your lead time. Limit WIP and lead time stabilizes. Stabilize lead time and forecasting gets dramatically easier.

Estimated backlogs. This one sounds obvious. It's not. Many teams estimate the items they're about to start and leave the rest rough. That works for sprint planning but it destroys milestone-level forecasting. If 40% of your milestone's items are unestimated, any forecast of the whole milestone has a giant unknown built into it. The forecast might look precise, but it isn't. The confidence interval should be wide enough to drive a truck through.

Fewer parallel tracks. Context switching degrades velocity in a fairly well-documented way. When team members split attention across multiple active milestones, each track moves slower than it would if the team was focused. This compounds the forecasting problem: more parallel tracks means more variance in which track gets attention in any given week, which means more variance in individual milestone progress, which means wider forecast ranges for everything.

These four signals are connected. Teams that limit WIP naturally have fewer parallel tracks. Teams with estimated backlogs can catch unestimated items before they become forecast surprises. Teams with consistent velocity have usually already solved the WIP and parallel work problems that cause variance.

The ritual that produces false confidence

When someone asks "when will this ship?" the typical answer is the spreadsheet forecast. A PM, tech lead, or founder opens a Google Sheet or a Jira report, looks at remaining work, estimates it roughly, divides by something like average velocity, adds a buffer, and sends a date. This takes maybe ten minutes and produces a number that looks precise.

The problem isn't the ten minutes. The problem is that this answer doesn't surface what it doesn't know.

It doesn't account for velocity variance. If your team's weekly output swings by ±40%, a point-estimate forecast will be wrong. It doesn't account for unestimated items, which add invisible mass to the milestone. It doesn't account for parallel work stealing capacity. And it doesn't propagate uncertainty through dependencies: if this milestone depends on another one that's also being estimated the same way, the error compounds.

A single date with no confidence interval is worse than no forecast at all, because it creates false confidence. Stakeholders anchor to it. The PM feels committed to it. And then reality diverges from the spreadsheet.

How GoalPath reads these signals automatically

GoalPath tracks all four predictability signals continuously, so you're not doing the Friday afternoon calculation from memory.

Velocity trend analysis. The velocity page shows weekly throughput over the rolling six-week window, with standard deviation surfaced alongside the average. You can see immediately whether your team is stable or swinging. A tight cluster of weekly bars means high-confidence forecasts. A scattered one means wide ranges are warranted.

Three-point forecasting. Every milestone forecast shows three numbers, not one: optimistic, most likely, and pessimistic completion dates. These aren't guesses. They're derived from actual velocity variance using a straightforward calculation: mean velocity plus or minus one standard deviation. It's not a Monte Carlo simulation. It's a direct translation of how consistently your team has delivered. A team that's delivered 9-11 points per week for six weeks gets a tighter range than a team that swings 5 to 18. The range is earned by consistency, or widened by variance.

Confidence levels. Each forecast carries an explicit confidence level (high, medium, or low), and what you get depends on both velocity consistency and how the forecast is calculated. Teams with their own dedicated velocity data and low variance (standard deviation below 50% of average velocity) get High confidence. Projects where GoalPath falls back to global or cross-team velocity data get Medium or Low depending on variance. When there isn't enough data at all (for example, a new team that hasn't yet built a velocity history), GoalPath falls back to historical averages or industry defaults, and the forecast will say so. Don't expect tight ranges from day one; the forecast gets more accurate as your delivery data accumulates. When you're looking at a forecast and it says "Low confidence," that's the system telling you the three-point range is real and wide. GoalPath surfaces this rather than hiding it.

Uncertainty propagation through dependencies. This is the part that catches most teams off guard. GoalPath schedules milestones sequentially within each team, ordered by priority. If earlier milestones have wide forecast ranges, later milestones inherit that uncertainty. A milestone can't start until the ones ahead of it finish. GoalPath shows the expected start date for a milestone including the cumulative slip potential of its predecessors. If the milestones before this one have wide confidence ranges, the start date range for this milestone reflects that honestly.

Unestimated item warnings. When items in a milestone haven't been estimated, GoalPath surfaces the count in the forecast panel with an explicit note that accuracy is reduced. This turns an invisible problem into a visible one. The fix is simple: estimate those items. But until you do, you see the forecast for what it is: partially informed.

Multitasking penalties. When your team is actively working across multiple milestones simultaneously, GoalPath applies a velocity reduction to each. Running two to three concurrent milestones applies a 15% capacity penalty. Running four to seven applies 30%. Running eight or more applies 50%. These tiers are based on the documented cost of context switching on effective throughput. There's also a separate velocity-division effect: team velocity is split across the number of milestones currently in progress, so each active track is effectively working with a fraction of total team capacity. The forecast you see already accounts for both of these parallel-work costs.

What changes when you look at this regularly

The forecast panel in GoalPath isn't just for when a stakeholder asks "when will this ship?" It's meant to be a regular part of planning and prioritization.

When you open a milestone and see a low confidence forecast with a three-week spread between optimistic and pessimistic, that's a signal to do something: estimate the unestimated items, split parallel tracks, address velocity instability. The forecast shows you the problem before it becomes a missed date.

When the forecast shifts (say, optimistic slips by a week after new items get added to the milestone), the change in the forecast is itself informative. GoalPath's progress reports include forecast deltas: "this milestone moved from May 12 to May 19 this week." That's the kind of early signal that lets stakeholders recalibrate before the date becomes a crisis.

This replaces the "where are we?" ping. Not because GoalPath automatically sends that email for you (though it does generate the weekly progress report draft), but because when stakeholders have a live, calibrated forecast instead of a stale spreadsheet date, the question answers itself.

The confidence you can give stakeholders

What separates teams that forecast reliably from those that don't is the quality of the underlying execution data, not the sophistication of their tools.

Teams that can say "we'll ship between April 28 and May 14, with the most likely date around May 5, at medium confidence" are giving stakeholders something real. Teams that say "probably mid-May" are guessing out loud. Both are estimates, but one has math behind it and the other has vibes.

GoalPath's forecast engine is built on six weeks of actual delivery data, standard deviation of your real velocity, explicit accounting for unestimated scope, multitasking cost, and dependency uncertainty. The forecast is as good as your execution data, and it tells you what would make it better.

That's the point. Not a better spreadsheet. A system that shows you the signals that drive predictability, in real time, so you can act on them before they become missed dates.

Further reading

• DORA metrics and software delivery performance: the research foundation for measuring delivery performance
• Little's Law and WIP limits: the math behind why WIP reduction improves lead time predictability (search for "Little's Law Kanban" for many solid explanations)
• Objectively measuring predictability: ASOS Engineering on how they quantify forecast accuracy
• Delivery metrics to improve predictability: Plandek on the metrics that signal whether predictability is improving

Almost done is not shipped.

If this sounds familiar, it's probably not a people problem. It's a flow problem. And the fix is not working harder or adding more people. It is finding where work stops moving.

What flow efficiency actually measures

Flow efficiency is a simple ratio: how much of an item's total lead time was spent with someone actively working on it, versus sitting in a queue waiting.

If a feature takes ten days from when it's created to when it ships, but people only worked on it for two of those days, your flow efficiency is 20%. The other eight days it was waiting. Waiting for a code review that didn't come. Waiting for a decision that never got made. Waiting for a dependency to unblock. Just sitting there.

Most software teams land between 15 and 25% flow efficiency. That's the industry benchmark, and it means 75-85% of the total time your work spends in your system, it's not moving. It's just waiting.

This is not a new observation. It comes from lean manufacturing, where teams measured how much of a part's total factory time was actually being processed versus sitting in a pile. The finding in manufacturing was the same: most of the time is wait time. Software is identical.

Why utilisation makes it worse

The instinctive response to slow delivery is to push people harder. Make sure everyone is busy. No idle engineers. Full calendars.

This makes flow efficiency worse.

When people are fully utilised, queues form. Think about a busy toll booth. The toll booth is at 100% utilisation. Every car is waiting in line. The queue grows because there's no slack to absorb variation. The moment you add one more car than the booth can handle, wait time spikes.

Software teams work the same way. When engineers are fully loaded, code reviews wait. Pull requests pile up. Decisions wait because the right person is context-switching between five things. Every queue you add to a fully-loaded system increases lead time.

Queuing theory has a name for this: the last 20% of utilisation causes a disproportionate increase in wait time. A team at 80% utilisation moves noticeably faster than a team at 95%, not because of 15% more capacity, but because at 80% there's enough slack that things don't pile up.

Measuring utilisation, making sure everyone looks busy, is exactly the wrong metric to optimise for.

How to tell if waiting time is your problem

You need to look at a few specific things.

First, look at lead time versus cycle time. Lead time is the total elapsed time from creation to delivery. Cycle time is the time from when someone started working on it to when it shipped. If your median lead time is 12 days but median cycle time is 3 days, 9 days of every item's journey is waiting. That's a 25% flow efficiency, which is average, but it tells you clearly that reducing wait time by half would cut your lead time by more than waiting-time reduction alone.

Second, look at which items are aging. Not all wait time is the same. Some items wait two days in a review queue. Some items sit started for three weeks. The ones sitting for three weeks are your flow blockers. Those are the ones where something is structurally wrong: no owner, unclear requirements, a dependency that nobody is chasing, a decision that hasn't been made.

Third, count how many items are in flight at once. If your four-person team has 18 items started, flow efficiency is going to be terrible. Not because people aren't working, but because the context-switching cost alone means nothing gets continuous attention. Work moves in bursts, waits in between, and lead times balloon.

The "alignment sync" is a symptom

Most teams respond to slow delivery by adding meetings. A weekly sync to check on blockers. A bi-weekly planning meeting to reprioritise. A quick alignment call to make sure everyone knows what's important.

These meetings are a symptom of invisible work. When you can't see where work is stuck, you schedule a meeting to find out. The meeting itself adds to wait time, because work is waiting for the outcome of the meeting before it can move.

The weekly status email is the same problem. You spend Friday compiling a report of what's stuck and what's moving, because without a system that surfaces this automatically, people don't know. And by Monday, the report is already out of date.

The replaced ritual is the meeting-to-find-out-where-things-are-stuck. Not the standup, not architecture decisions. The specific meeting where someone asks "what's blocking us?" and nobody has a good answer until everyone has spoken.

What GoalPath shows you

GoalPath calculates flow efficiency automatically from how your items move through the workflow. When you look at the Velocity Analytics page, you see four metrics side by side: Flow Time, Flow Efficiency, Flow Distribution, and Flow Load.

The Flow Efficiency card shows your efficiency percentage with a benchmark label. Below average (under 15%), Average (15-25%), Above average (25-40%), or Excellent (above 40%). You know immediately whether your waiting time is typical or a real problem to fix.

But the number alone doesn't tell you where to look. The Flow Load section does that.

GoalPath buckets every in-progress item by how long it's been started: fresh (3 days or under), normal (4-7 days), aging (8-14 days), stale (15-30 days), and stuck (over 30 days). The Flow Load card shows your total WIP count, how many items are stale or stuck, and a summary badge.

If you have seven items in the "stuck" bucket, those are not delivery problems. They're decision problems, dependency problems, or ownership problems. Each one is adding wait time to your lead time without any active work happening.

GoalPath records when items are created, when they're started, and when they're completed. That's all the data it needs to calculate flow efficiency and aging automatically. You don't report into it. You just work, and the insight comes from the workflow data.

Where work actually gets stuck

Once you can see aging items by milestone, a pattern usually emerges. Work tends to stack up in one or two specific places:

Review queues. Items waiting for someone to review or approve them. This shows up as a cluster of aging items with no clear next owner. The fix is usually to make ownership explicit: someone specific is responsible for moving this item, not "whoever has time."

Decision dependencies. Items that are started but can't proceed until a decision is made elsewhere. These are easy to miss because they look like normal WIP. The fix is to make blocked items visible. Set the Blocked highlight in GoalPath so the team knows this isn't just slow, it's waiting on something external.

Milestone overload. One milestone has twelve items in progress because it's where everything important lives. Flow efficiency for that milestone will be terrible. The fix is WIP limits: not twelve things in flight, but three, with the rest explicitly queued.

Unclear requirements. Items that are "started" but the developer is waiting for clarity. Often nobody has marked them blocked because it feels like their fault for not knowing the answer. These show up as stale items where the last activity was weeks ago.

The GoalPath Insights engine can diagnose this for you. Ask it "Where is work getting stuck?" and it will look at your flow metrics, your current WIP, your aging distribution, and your velocity data, and give you a specific answer grounded in your project's actual data, not generic advice, but a diagnosis tied to what's actually happening in your workflow.

What to do about it

The specific fix depends on where the bottleneck is, but the pattern is the same in most teams.

Start by finding your stuck items. In GoalPath, sort your in-progress items by age. Look at anything that's been started for more than two weeks without moving. For each one, ask: what needs to happen for this to move? If there's an answer, make it explicit. Assign an owner. Set a Blocked highlight if it's waiting on something external. If there's no good answer for why it's started, consider moving it back to not-started. The started status should mean "actively being worked on", not "we plan to work on this eventually."

Then look at WIP. If your flow load card shows 18 items in progress for a four-person team, you need to finish before you start. That's the core discipline. Not as a rule for its own sake, but because each additional started item adds queue time to everything else.

Finally, check the milestone distribution. If one milestone is carrying most of the in-progress items, look at whether those items are genuinely active or just parked there. Milestones become catch-all buckets when there's no forcing function to finish things before adding new ones.

Improving flow efficiency is mostly about removing friction

You don't improve flow efficiency by working faster. You improve it by removing the things that make work wait.

Code reviews that sit for three days are not a reviewer productivity problem. They're a queue problem. The reviewer is fully loaded. Adding a norm of "reviews within 24 hours" without changing anything else just adds stress without changing the queue dynamics.

What changes the queue is smaller WIP. When people have fewer things in flight, they have more capacity to respond when something needs attention. The review queue gets reviewed faster not because reviewers are working harder, but because they have the bandwidth to see it.

Most teams that improve their flow efficiency do it by finding the two or three specific places where work consistently piles up, and doing something structural about each one. Not a process improvement initiative. Just: this keeps getting stuck here, what can we change to stop that?

GoalPath tells you where those places are. The rest is a conversation about what to do about them.

Further reading

• Flow Efficiency: A great metric you probably aren't using: Kanban University's explanation of the metric and why most teams ignore it
• Our survey says: uncovering the real numbers behind flow efficiency: ASOS Tech Blog survey of 63 teams and their actual flow efficiency numbers
• Flow & Queueing Theory: LeSS framework explanation of why high utilisation creates queues

You planned the sprint. Everyone had their work lined up. Then a customer escalated. Then someone found a bug in production. Then a stakeholder pinged about "just one small thing." By Friday, half the planned work is still in progress, and the team is defending why they didn't hit the milestone.

This is not a planning failure. It's a ratio problem.

If you have been in software for a while, you know this pattern. The plan looks solid on Monday morning. By Wednesday, real life has started editing it. By Friday, the original plan and the actual work barely resemble each other. The frustrating part isn't that things changed. It's that the changes weren't tracked, so nobody can tell whether the team underperformed or whether the plan was hijacked.

Telling the two apart is what makes it possible to fix the right thing.

Unplanned work is not the enemy

Most articles about scope creep get this wrong. Unplanned work isn't always bad. If a production outage hits, you want your team to respond. If a customer surfaces a blocking bug the day before their contract renewal, you handle it. A team that ignores all unplanned work because "it wasn't in the sprint" is a team that's optimizing a process at the expense of outcomes.

The goal isn't zero unplanned work. The goal is knowing what the ratio is, and making a conscious call about what that ratio should be.

Most teams never measure it. They just experience it. The sprint ends. Things slipped. There's a vague feeling that "a lot of stuff came up." Then the cycle repeats.

A team consistently running 10-15% unplanned work is probably healthy. Responsive, but not chaotic. A team running 40% is reactive. Work is arriving faster than it can be absorbed, forecasts are meaningless, and the planned roadmap is a fiction that gets politely ignored. The 2024 DORA research found that unstable organizational priorities are among the strongest predictors of developer burnout. Chronic high unplanned work is exactly that kind of instability, just at the sprint level.

What your planning ritual is actually telling you

Most teams handle unplanned work through conversations. Someone raises something in standup. It gets added to the board. Sprint planning gets "adjusted." The velocity numbers at the end of the sprint don't reflect the interruptions, so the forecasts keep being wrong in the same direction, week after week.

The ritual this replaces is the informal scope-change conversation. The "can we just add this in?" moment that happens in Slack, in the hallway, in standup. Nothing wrong with those conversations. The problem is that without a structured intake, they're invisible to everyone except the people in that channel at that moment.

When you have no structured triage, you have no data. And without data, the conversation about what the right ratio is never happens. The team is always reacting, never calibrating.

What GoalPath tracks and why it matters

GoalPath detects unplanned work automatically through two distinct mechanisms.

The first is automatic scope detection. Any item added to a milestone that is already in progress gets flagged automatically. No manual tagging required. The moment someone adds a bug fix or a new task to a running milestone, GoalPath marks it as unplanned.

That flag shows up in a few places.

On the item itself: an orange "Unplanned" badge appears next to the status. Anyone opening the item can see immediately that this wasn't part of the original plan. The tooltip explains: "This item was added after the milestone started. It contributes to scope creep and may impact forecast accuracy."

The second mechanism is the triage inbox, a separate intake queue for work that arrives without a home. Items without an assigned milestone, or new requests that haven't been prioritized yet, land here. The inbox is GoalPath's structured alternative to ad-hoc Slack conversations. Each item can be assigned a triage priority: Incident (drop everything), Expedite (next in queue), Standard (work it in normally), or Deferred (acknowledge it, park it for later).

These are distinct mechanisms: the automatic scope detection tracks items added after a milestone started, while the triage inbox handles the intake flow before items are placed anywhere. Together, they give unplanned requests a visible home and a deliberate process, rather than a hallway conversation that only a few people heard.

In the velocity analytics: GoalPath tracks your unplanned work ratio week by week across the project. Not just this sprint, but the trend over 12 weeks. You can see whether your ratio is creeping up, stabilizing, or improving. You can filter by team to see if the interruptions are distributed evenly or hitting one team harder.

The velocity chart itself shows the split visually. Orange bars are planned work, blue bars are unplanned. When the blue starts growing relative to the orange, you can see the interruption pattern forming before it shows up in a missed forecast.

The flow distribution view tells a different story

There's another angle that's easy to miss. The flow distribution chart in GoalPath's insights view shows your completed work broken down by type: Features, Bugs, and Tasks, tracked week by week.

If your bugs column is quietly growing, that's often a sign of reactive work accumulating. Features require planning. Bugs arrive. A healthy product team in a growth phase should be heavy on features. A team maintaining a legacy system might legitimately run 50% bugs. But if you're supposed to be building a new product and your distribution is quietly shifting to 60% bugs and 40% features, that's the data telling you something about where the interruptions are actually coming from.

Flow distribution doesn't just show what you shipped. It shows whether the thing you're building matches the thing you planned to build.

How forecasts absorb the data

The unplanned work data feeds directly into delivery forecasts, not just dashboards. GoalPath uses your historical unplanned work ratio to automatically adjust delivery forecasts.

If your last ten completed milestones averaged 20% unplanned work, GoalPath applies a 1.2x multiplier to future duration estimates. That 10-week milestone is probably a 12-week milestone when you account for the interruptions that will arrive. The adjustment is weighted toward recent milestones, so if your team has been getting better at triage, the forecast improves accordingly.

You're not just looking at the number after the fact. The number feeds forward into the forecast so stakeholders see realistic timelines, not optimistic ones.

Most teams don't have this. They have a sprint board and a gut feeling. GoalPath has the data from your last ten milestones, weighted by recency, baked into the next delivery estimate.

A simple way to read your own ratio

If you start tracking unplanned work today, here's a rough frame for what you're seeing. These are rules of thumb, not benchmarks from a study. Treat them as a starting point for your own calibration.

Under 15% is generally healthy. Some responsiveness is normal and good. Your planned work is mostly protected.

15–30% is worth watching. You're not in crisis, but unplanned work is taking a meaningful bite out of capacity. Worth a conversation about whether the triage process is working correctly. Are expedites being over-used? Are incidents being handled with the right level of urgency?

Above 30% consistently means the planning is probably not trustworthy. Stakeholders sense this even if they can't name it, which is often why they start asking "where are we?" multiple times a week. The forecast they were given doesn't match what they're observing. The fix isn't better planning. It's tightening the intake process, being more deliberate about what gets expedited, and surfacing the ratio explicitly in alignment meetings.

GoalPath's alignment meeting flow includes a flow health stage that surfaces active blockers, WIP limit warnings, unresolved escalations, and at-risk or stale milestones. These are the things most likely to derail the plan before the team even touches new priorities. The unplanned work ratio and flow distribution live on the Velocity Analytics page, and the alignment meeting is a natural moment to bring that data into the room before any new priorities are set. That conversation used to happen informally, in different places, with different people having different information. The alignment meeting makes it a standing ritual with the actual numbers in front of everyone.

The question the ratio answers

The question teams always struggle with is: are we slow, or were we just interrupted a lot?

Without the data, you can't answer it. The standup after a rough sprint usually produces a mix of vague explanations and defensive justifications. Everyone knows things went sideways. Nobody can say why with any precision.

With the unplanned work ratio, you can answer it in one number. If the ratio was 35% this sprint, the team wasn't slow. A third of their capacity was consumed by work that arrived after the plan was set. That's a different conversation than "we underestimated" or "people weren't focused."

It also tells you what to work on. If the ratio is high because of bugs, you have a quality problem. If it's high because of customer escalations, you have an expectation management problem. If it's high because stakeholders keep adding things mid-sprint, you have a prioritization governance problem.

The number points at the root cause. From there, you can actually fix something.

Further reading

• 2024 DORA State of DevOps Report: burnout research and organizational stability findings
• Accelerate State of DevOps 2022: unplanned work benchmarks and interrupt-driven work patterns

Someone asks when a feature will ship. You do a quick mental calculation: sprint ends Friday, a couple items are in review, maybe next week. You say "end of next week" with reasonable confidence. Two weeks later it is still not done, and you are back in that conversation.

This is not a planning failure. It is a measurement failure. The number you gave was based on a guess dressed up as an estimate. The actual data was sitting in your project history the whole time, but nobody had surfaced it in a useful form.

There are three distinct time measurements that matter in software delivery. Most teams confuse them or use them interchangeably. Once you understand the difference, you can give stakeholders an answer that actually holds.

Lead time, cycle time, wait time: not the same thing

Lead time is the total clock time from when a piece of work enters your system to when it ships. It starts when someone creates the item and ends when it is accepted. From a customer or stakeholder perspective, this is the number that matters. It answers "how long does it take to get something done around here?"

Cycle time is the narrower slice: the time from when your team actually starts work on an item to when it is done. The cycle time clock begins the moment someone moves it out of NotStarted (whatever that first active status is). This is the number your team can most directly influence.

Wait time is the remainder. Lead time minus cycle time. It is all the time an item sat in someone's queue before anyone touched it: the days it spent in the backlog, waiting for review, blocked on a dependency.

The relationship is simple: lead time = cycle time + wait time.

Why does the distinction matter? Because they have completely different causes and different fixes.

If your cycle time is high, something about how your team actually executes is slow. Too many items in progress at once, unclear requirements at the start, slow code review, complex work that was underestimated.

If your wait time is high, the work is fine once someone picks it up. It is just not getting picked up. The backlog is too deep, items sit unassigned, reviews take days because the reviewer is juggling five other things.

Most teams trying to "improve velocity" attack cycle time when their real problem is wait time, or vice versa. They run faster at the wrong part of the system. That is why separating the two is not just an academic exercise.

The average will mislead you

Here is a trap most teams fall into: they look at average cycle time. Their average is five days, so they promise delivery in a week. Then 30% of items take twelve days, and the promise is broken.

Averages are pulled by outliers. One item that gets stuck for three weeks drags the average up, but most items finish in four days. Using the average to make promises is optimistic about the typical case and still wrong about the edge cases.

A better approach: instead of the average, look at the number that 85% of your items actually finish within. GoalPath calculates this automatically. If that number is nine days, you can tell a stakeholder that nine out of ten items will be done within nine days of starting. That is a commitment you can actually keep, because it accounts for the realistic spread of your work instead of pretending everything takes the average.

A 12-person engineering team at Siemens Health Services had an 85th-percentile cycle time of 62 days. After introducing explicit WIP limits, it dropped to 36 days, a 42% improvement with no change in team size. Measuring cycle time percentiles gave them the evidence to act on a problem they already suspected but could not quantify. (Source: Agile Alliance case study)

Most teams are surprised by their flow efficiency

Flow efficiency is the ratio of cycle time to lead time, expressed as a percentage. If the average lead time for your items is 10 days and the average cycle time is 2 days, your flow efficiency is 20%.

Most software teams land between 15% and 25% when they first measure this. (Source: Kanban University) That means work is actively being worked on for roughly one day out of five. The other four days it is sitting in a queue somewhere.

Teams that have not measured this before tend to be surprised. They thought their process was fairly lean. The data says otherwise.

High-performing teams push this toward 40% and above. That does not mean everyone is coding all the time. Some waiting is inherent and even valuable (code review, QA). But it does mean you understand where the wait is happening and you have made a deliberate choice about it rather than having it accumulate invisibly.

How GoalPath shows this to you

On the Velocity Analytics page, the Flow Time card shows lead time, cycle time, and wait time together, covering the last 12 weeks of completed items. It leads with the lead time median because that is what stakeholders experience. Directly below it, cycle time and wait time show you the split: where your process is healthy and where it is not.

The trend badge compares average lead time across two 12-week windows, so you know if your changes are moving things in the right direction. Next to it, the Flow Efficiency card shows your efficiency percentage with a benchmark label (below average, average, above average, or excellent) so you can calibrate against what other teams achieve.

The ritual GoalPath replaces

Before a team has this data, cycle time conversation tends to happen one of two ways.

The first is the "where are we?" sync. A stakeholder asks for a status update, someone pulls together a rough summary based on memory, and you have a 30-minute meeting where the real answer is "probably next week, we think." This happens every time someone needs a delivery estimate. The PM becomes a real-time translator between the work and the question.

The second is the end-of-sprint retrospective number. Teams record their velocity, maybe track some story points, and call it a day. Nobody breaks down whether the time went into active work or into waiting. Nobody has a number they can quote with confidence.

GoalPath eliminates both by turning the execution data your team already produces into metrics that answer the question directly. When someone asks "when will this ship?", you open the Velocity Analytics page, check the cycle time median and trend on the Flow Time card, and give an honest number grounded in your team's actual history. No meeting. No mental arithmetic. No optimism disguised as a forecast.

The mechanism: GoalPath captures when each item is created, when work begins on it (when it moves out of NotStarted), and when it is completed (set to Accepted). Those three timestamps are all GoalPath needs to compute lead time, cycle time, and wait time. Because the workflow is structured, with teams moving items through defined statuses rather than typing status into a free-text field, the timestamps are consistent and reliable by default.

What to do with a high wait time

If you look at your Flow Time breakdown and see that cycle time is three days but lead time is twelve days, your wait time is nine days. The team is not slow. The queue is.

The most common causes:

Backlog depth. Items sit unstarted for days because there are thirty items in the backlog and the team picks up new work in the order it was created rather than by priority. Fixing this means being more deliberate about what goes into the active sprint or milestone, so fewer items sit untouched.

Slow handoffs. An item finishes development and waits three days for QA. Or code review happens in batches on Fridays. The work is done but it has not moved. Making handoffs explicit and time-boxed (a 24-hour review SLA, for instance) attacks this directly.

WIP accumulation. When everyone has four or five items in progress simultaneously, everything moves slowly. Items that have already been started sit in review queues while the developer has moved on to the next thing. Reducing active WIP is often the fastest way to shrink wait time, not because people work faster, but because there is less work waiting for attention at each handoff.

GoalPath's Flow Load card shows you current WIP and aging: how many items are fresh (under 3 days), normal, aging, stale, or stuck (over 30 days). If you see a lot in the stale and stuck categories, your wait time problem has a name.

What to do with a high cycle time

If cycle time is high but wait time is low (work gets picked up quickly but takes a long time to finish), the problem is different.

Look at item size. Large items that take two weeks each will have high cycle time almost by definition. Breaking items into smaller increments (under three days of active work) will reduce the median and tighten the distribution.

Look at rework. In GoalPath, items that fail review get set to Rejected and need to be restarted. If you see a pattern of items cycling through Rejected and back to Started, the active work time is being inflated by revision cycles. This usually points to requirements clarity at the start, not execution speed.

Look at context switching. A developer working on five items simultaneously is not doing five days of focused work on each. They are doing one day here, two days there, interrupted by a higher priority. The actual cycle time is long not because the work is hard but because the clock is running while the item waits for attention from its own owner.

The 85th percentile is the most useful number here. If the median is four days but 85% of items finish within fourteen days, you have a small number of items that are taking much longer than typical. Find the pattern in those outliers. They usually have something in common.

Trend indicators tell you if your changes are working

One of the harder parts of process improvement is knowing whether what you changed made a difference or whether the numbers moved because of randomness.

GoalPath compares your current 12-week window to the previous 12-week window and shows whether lead time is improving, stable, or worsening, along with the percentage change. This is the trend badge on the Flow Time card.

If you reduce WIP limits and three weeks later you see the trend badge flip to "Improving 18%", that is signal. You have a number attached to the change. If it stays stable or moves to "Worsening", you have information too: either the change did not work or something else is counteracting it.

Without this comparison, teams guess at whether their process changes are working. With it, you have a 24-week view of the direction your delivery speed is moving.

The short version

Cycle time is how long items take once your team starts them. Lead time is how long they take from creation to done. Wait time is the difference: the invisible queue time that most teams never measure.

The median cycle time is what you quote to stakeholders for a realistic delivery estimate. The 85th percentile gives you a safer number that accounts for the realistic spread of your work.

GoalPath computes all three metrics automatically from your workflow timestamps, shows you the trend, and benchmarks your flow efficiency against industry data. You do not need a separate analytics tool or a Friday afternoon ritual to produce this information. It is on the Velocity Analytics page, updated daily.

The "where are we?" ping from your stakeholder is a symptom of not having this data visible and current. Once you do, the question mostly answers itself.

Further reading

• ProKanban: Signalling Work-in-Progress with Cycle Time Percentiles: why the 85th percentile is the right number for delivery commitments
• Scrum.org: Getting to 85 (Agile Metrics): the case for percentile-based forecasting over averages
• Kanban University: Flow Efficiency: why 15-25% is typical and how to improve it
• DORA 2025 Report: software delivery performance benchmarks across thousands of teams

The velocity number told you nothing useful about this. It never does, until after the fact.

What velocity actually measures

Velocity tells you how much work your team completed over some past window of time. It's useful for forecasting. It's not useful for telling you whether your team is going to have a good week, or a bad one, before it happens.

Velocity tells you how far you drove last week. WIP tells you how many cars are on the road right now. One is history, the other is a prediction of what happens next.

When your WIP is high and climbing, velocity will eventually show you the damage. But by then, you've already spent a few weeks in trouble. That's why WIP is a leading indicator and velocity is a lagging one.

Little's Law, explained without the textbook

There's a formula called Little's Law that comes from queuing theory. You don't need the math. The principle is this:

Lead time = WIP divided by throughput.

If your team completes 5 items per week and has 5 things in progress, the average lead time is 1 week. If that same team starts 20 things at once while still completing 5 per week, average lead time jumps to 4 weeks. Same team. Same throughput. Four times longer to get anything done.

That's not theory. That's what happens in most teams. Items get started because they seem urgent. Nobody explicitly decides to have 20 things in progress. It just accumulates. And every item added to the pile makes every other item slower.

The counterintuitive part: finishing one thing and starting nothing new is faster, for the team's overall output, than starting two new things and having three things "almost done."

Why "almost done" is almost worthless

There's a useful question to ask about any item that's been in progress for more than a week: what's the actual customer value of 80% done?

Usually the answer is zero. A feature that's deployed and in users' hands is worth something. A feature that's still in a branch, or waiting for a final review, or needs one more thing before it can ship, is not generating any value yet. It's inventory.

The longer things sit in "almost done" status, the more they accumulate risk too. Code that's been sitting in review for two weeks while other work has been merged is going to have conflicts. The person who wrote it has moved on mentally. The context is gone.

High WIP is how "almost done" becomes "actually never done." Things get superseded, de-prioritized, forgotten. The team was busy the whole time.

The pattern that accelerates the problem

Without WIP discipline, the spiral goes like this.

Team has 10 things in progress. Nothing is finishing because everyone is switching contexts. A stakeholder gets impatient about feature X, which has been in progress for two weeks. Team lead adds feature X to the standup agenda. Someone else notices feature Y is also delayed. Both get attention. Two more things get started to unblock them. Now there are 14 things in progress.

At the next sprint review, velocity looks okay because the team did complete some things. But lead times are getting longer. The stakeholder still doesn't have feature X. There's another alignment meeting to "figure out what's going on."

That alignment meeting is the replaced ritual. Teams do this regularly: a Monday sync, a mid-sprint check-in, a "what's blocking us?" call. The intent is to surface problems. The problem is, by the time it surfaces in a meeting, you've already been slow for two weeks.

You need to see it while it's happening, not after.

What GoalPath's Flow Load view shows you

GoalPath tracks WIP at two levels: milestone WIP (how many milestones are currently in progress) and item WIP (how many items are in progress). Both are visible in the Flow Load section of the Velocity Analytics page, with a per-person breakdown available in the Flow Load card.

The Flow Load card shows you total WIP right now and breaks it into aging buckets: fresh (0-3 days), normal (4-7 days), aging (8-14 days), stale (15-30 days), and stuck (over 30 days). That last bucket is the number to watch. A few "fresh" items is expected. Growing "stale" and "stuck" counts are how WIP problems show up before they're visible in velocity.

The per-person breakdown shows you each team member's current WIP count and their oldest item in days. If someone has 6 items in progress and their oldest has been running for 18 days, that's not a people problem. That's a coordination problem that management created by assigning too much at once, or by not having clear enough completion criteria.

GoalPath also shows this automatically during your alignment meeting. In the Flow Health & Escalation stage, if the team is over the WIP limit (calculated as teams × 2 for milestones, or collaborators × 1.7 for items), it surfaces a warning so the team can discuss it before continuing. That conversation replaces the ad-hoc "where are we on everything?" pings that would otherwise interrupt engineers mid-week.

Velocity dashboard: what the data is actually telling you

The velocity page shows you per-team velocity charts alongside the flow metrics. It's designed to be read together, not separately.

If velocity is dropping week-over-week while Flow Load shows rising WIP, that's the Little's Law effect happening in your project. The team isn't getting slower, they're just drowning in context-switching. The fix isn't to work harder. It's to finish things before starting new ones.

If velocity looks steady but your Flow Time (lead time median) is climbing, you have items completing regularly but new items are spending more time waiting before they get touched. That's often a sign of too many parallel workstreams, where each team member is spread across multiple milestones and nothing gets undivided attention.

GoalPath applies a multitasking penalty to forecasts automatically. Across 2-3 milestones, effectiveness is 85% (15% penalty). Split across 4-7 milestones, it drops to 70% (30% penalty). At 8 or more milestones, it falls to 50% (50% penalty). This is not a punishment, it's math. When you see a forecast slip in GoalPath, check whether it's because of increased WIP rather than reduced capacity. Usually it is.

The practical check

You don't need to wait for a sprint retrospective to see if WIP is a problem. You can check right now.

Open your items list. Count everything that's Started, Delivered, or Rejected but not yet Accepted. GoalPath counts all of these as work in progress. Divide by the number of people on the team. If the average is more than 2, you're running hot. If anyone has more than 3 active items, they're context-switching and probably not making meaningful progress on any of them.

Then look at the oldest started item. How many days has it been active? If the answer is more than two weeks and it hasn't shipped yet, that item is probably suffering from the "almost done" problem. There's a reason it hasn't finished, and that reason is usually related to something else that was started before it completed.

The fix isn't complicated. Stop starting. Start finishing.

The team picks the three most important in-progress items. Everything else gets paused, explicitly. No half-work. No "I'll keep making small progress on it." Paused means paused. Then you work until those three are done. After that, you start three more.

Most teams see lead times drop in the first two weeks of doing this. Not because anyone worked harder. Because context-switching stopped eating the hours.

A note on velocity as a target

Velocity should not be a goal. If your team starts breaking items into smaller pieces to pump up the point count, your forecasts get worse, not better. If people mark things done before they're actually in users' hands, you lose the signal.

WIP counts are harder to game than velocity numbers. Either something is in progress or it isn't. Either it's been running for 20 days or it hasn't. That's why watching WIP aging gives you a more honest picture of team health than watching velocity points.

Velocity is how you forecast. WIP is how you manage. Both matter, but if you're only watching one, watch WIP.

Further reading

• Little's Law explained for software teams: https://leankit.com/learn/kanban/littles-law/
• Troy Magennis on WIP and cycle time: https://focusedobjective.com/free-tools-and-research/
• DORA 2024 report on software delivery performance: https://dora.dev/research/2024/dora-report/
• Daniel Vacanti's work on flow metrics and forecasting: https://actionableagile.com/resources/

If you have worked in software for a while, especially in startups, you might have noticed that the priorities always seem to shift. Someone met a potential customer, and they really liked the idea of an automatic tax statement, next week we really need to have an integration to Google Workspace only to two weeks later have to onboard someone who is using Office 365.

The team just keeps on building, never sure that what they shipped last week still matters to anyone.

You could say that it's a lack of vision or a goal. But in reality, working with product development is about balancing multiple goals against each other, and this is often something that takes a lot of time and resources. A product manager or owner holds multiple meetings with both developers and sales and marketing, only to 3 weeks later hold the same meetings again. This time, with a different outcome.

Or the choice of the next feature to develop is dictated by the head of sales who "has a lead on the great next deal". The urgent Slack ping. The hallway ask. The VP who's most visible this week. Teams don't choose those things because people are lazy. They choose them because leadership hasn't made trade‑offs visible. When everything is Priority 1, the loudest stakeholder wins.

When planning is based on gut feel and emotions, the long term plan suffers. No product vision or big hairy audacious goal will help you, if you don't show how to take that vision to reality. Not with a perfect plan, but with a guiding strategy.

If prioritization is a leadership visibility problem, the solution isn't another spreadsheet. You need a visible, defensible system that turns stakeholder preference into a ranked agenda the team can trust.

Why this matters

Unclear priorities create a feeling that you're not progressing, you are not achieving a goal. The every day can feel productive, and filled with wins. But if you zoom out and take a look at a 6-months span, you haven't actually made progress. Your product is basically the same, but with a few new additions. Longer feature development where features build on each other to compound business value becomes impossible. The idea of being able to do better and better each week, month, year loses validity and inevitably in this climate, it means you fall behind. Either you lose customers, or you lose talent frustrated that nothing changes.

How to break the cycle

There are two strategies that I recommend to break this trend. To create structure, while still allowing people to come up with ideas and help align to a vision. Having a vision or big hairy audacious goal (BHAG) is great. But to achieve the goal you need to have a plan of how to get there. You might not follow the plan to the letter, there might be backup plans. But a roadmap to reach that goal is important.

Reverse planning

In engineering and military planning there is a concept called reverse planning. Let's use a simple example, silly but simple. Let's say we're going to the moon.

If we want to reach the moon, we will need a moon lander, to get the moon lander to the moon, we will need a rocket, to launch the rocket we will need a launch pad.

The idea is that for each goal we see, we ask ourselves a single question "What do we need to get here?".

This is greatly simplified, but breaking the big hairy audacious goal down into smaller goals by asking the same question over and over again, is a great way to create a roadmap of what needs to be done to achieve the goal. Your great vision becomes that guiding star, the reverse planning process helps you ideate and develop the plan. It might even show you multiple ways to reach the goal.

We do this in GoalPath, creating a visual roadmap, giving you options of how to reach the goal, or just shows the path there.

Prioritising and choosing a path

Strategic thinking is not the default operating mode of most minds. Most people need to put their mind into planning or logic mode to assess if something is actually the right choice. A good way to do this is to have them vote. GoalPath supports multiple voting frameworks, you can even have your own. But what this does is that it forces you to take a step back and think about something from a few clarifying questions. If you create your own voting questions, you can have it align to your vision, further enforcing that we are trying to achieve a vision or goal. You can of course do this in Excel or any spreadsheet software if you wish, that's what I did before I made GoalPath.

For early stage startups or solo developers (yes, solo developers need structure too) a simple framework such as MoSCoW is a good starting point until you created a first version, or it's becoming harder and harder to choose between your options. If you work for a non-profit or have a specific and very clear vision, taking the time to create your own questions could be worth it. I recommend doing that in a workshop fashion with your stakeholders.

Having multiple people vote creates inclusion and draws on crowd intelligence, and inevitably helps make alignment and adoption easier.

GoalPath will take the votes and normalise the results to a business value score between 1-100. All of a sudden, you will be able to sort what you plan to do based on the value you think it will provide. Meaning you can compare features to each other based on a strategic value instead of someone's eagerness or loudness.

Now if you sort them based on the business value, you will be able to quickly focus your prioritisation and planning efforts on the most valuable parts of your plan.

Ordering becomes simple - but we still need to respect the plan

An ordered list is a great start to a backlog, but simply ordering on business value is not enough. A technical Product Manager might be able to respect dependencies, but it might not be enough. Some things just need to be in order. Coming back to the space program, we can't have a moon landing without a rocket to get us there.

Since we did the reverse planning in roadmap view, we captured the dependencies between the milestones we needed to reach to achieve our BHAG. GoalPath can now automatically create a rough backlog of which things to do in what order to reach the goal, using the dependencies and the business value as a guide. Again, creating a backlog for you to follow, and helping you focus on the most important next steps of the plan.

Show the plan

Clearly showing everyone the plan, and making it accessible. Involving people in the design of it, allows the rest of the team to "make the right choice" because they know where we are going. It might not be 100% perfect, but without a framework, a vision and a structured plan to get there team members are robbed of the ability to make the right choice.

Having

• Business‑value voting collected from stakeholder preferences.
• A roadmap showing how we will reach a goal
• A structured backlog showing what order to execute things

Creates a combination that turns preferences into a defensible priority order and makes the decision visible where teams work.

The loudest voice stops being the de facto decider because the priority ranking and rationale live in the tool.

Your sprint ends Friday. People look tired. Slack never stops. And when you ask “what shipped?” you get guesses, not dates.

Busy calendars. Lots of activity. Little delivered.

This is not a people problem. It’s a flow problem. Work spends most of its time waiting. If you fix the waiting, delivery follows. Here’s how to tell in 30 minutes, and what to run in the next two sprints.

Diagnose in 30 minutes

Do these three quick checks. Each one has a single red flag. If any flag is red, you likely have too much in progress.

1. Focus‑time sanity check (≈5 minutes)

   • Open two or three engineers’ calendars at random. Do they have at least one uninterrupted 3‑hour block per day (or ~3 hours total of long blocks)?
   • If calendars are chopped into 30–60 minute meetings, context switching will eat the day. (See meeting benchmarks for engineers.)
   • Red signal: no long uninterrupted blocks.

2. WIP headcount (≈5 minutes)

   • Look at your board. Count items in Started/In‑Progress and divide by engineers.
   • If the average is >1–2 active items per engineer, you’re likely multitasking too much. Little’s Law explains why more WIP increases lead time.
   • Red signal: engineers juggling 3+ started items.

3. Flow‑efficiency quick read (≈15 minutes)

   • Pick five recently delivered items. Compare active work time (hands‑on + review) to total lead time (created → delivered).
   • Many teams sit at 15–25% flow efficiency, meaning 75–85% of lead time is waiting rather than active work (reviews, decisions, dependencies).
   • Red signal: >70% waiting time.

If any check is red, adding heads or more meetings won’t help. You need to reduce things in flight and speed decisions.

The short list of root causes

When teams look busy but don’t ship, the causes are predictable:

• Decision latency: approvals and unclear owners create queues.
• WIP overload: too many parallel items increases switching and review queues.
• Meeting fragmentation: frequent short meetings break flow.
• Tool or workflow mismatch: tooling amplifies work only when the flow is healthy.
• Unclear ownership and handoffs: items wait for the right person to notice them.

Fixes should target queues and wait time, not raw activity.

Five fast experiments (1–2 sprints)

Pick two or three. Run them with an owner, a stop criterion, and one metric to watch.

1. Protect focus blocks (1 sprint)

   • Reserve two 90‑minute deep‑work windows per developer per week.
   • Replace one recurring sync with a 3‑line async update: Done / Next / Blocker.
   • Watch: PR throughput, median lead time. Teams using protected focus see big gains in shipped features.

2. One‑week WIP pilot → tune for 2 sprints

   • Limit in‑progress items to 1–2 per engineer. Finish before you start.
   • Watch: median cycle time, throughput, defect rate. WIP limits commonly cut cycle time 20–40% in case studies.

3. Meeting surgery (1 sprint)

   • Cancel low‑value recurring meetings. Try one or two no‑meeting days.
   • Move status updates to a short async report.
   • Watch: focus hours/week, developer satisfaction.

4. Decision‑DOT (Decision Owner Table) (1–2 sprints)

   • List common decisions: what, owner, required inputs, SLA. Set a 24–48 hour SLA for non‑critical approvals.
   • Watch: blocked time and SLA compliance.

5. Baseline delivery metrics (30–90 days)

   • Track median & 85th‑percentile lead time, flow efficiency (rough), PR throughput, and percent unplanned work.
   • Use these as your control before and after experiments.

Don’t optimise flow blindly

• Some synchronous work is necessary (architecture, incidents). Don’t remove all meetings.
• Tune WIP limits experimentally; rigid limits can create artificial idle time or gaming.
• AI tools amplify output, but they amplify dysfunction if decision latency remains.

30 / 60 / 90 playbook for teams of 5–20 engineers

• 30 days: protect focus time; remove low‑value meetings; capture velocity baseline and unplanned work ratio.
• 60 days: apply WIP limits; introduce Decision‑DOTs; keep dashboards visible in cadences.
• 90 days: measure lead time improvements, scale successful practices across value streams.

How GoalPath helps (practical, concrete)

GoalPath exists so you can run these experiments without extra process overhead and measure impact reliably.

• Automatic weekly progress reports: drafts of plain‑English updates are generated from actual execution data. Replace the Friday status email with a draft you review and send.
• Guided meetings: built‑in standup and alignment facilitators surface blockers, triage unplanned work, and capture decisions. No 50‑page wiki or outside facilitator required.
• WIP & triage affordances: Inbox, Unplanned badges and triage dialogs make scope creep visible the moment it happens.
• Velocity & forecasting: see velocity trends, probability bands and cascading forecasts so you can show stakeholders defensible dates and understand how WIP or a delayed dependency shifts the critical path.

Start small: create a project, run the two‑sprint experiment above, and let GoalPath generate the baseline reports for you. You should see your first automatic progress report within a week.

Final note: a test you can run tomorrow

Run these three steps in your next two sprints: protect focus, cap WIP, prune meetings. Measure median lead time and PR throughput before and after. If you’re honest about the data, you’ll usually find the fastest way to ship more is to start fewer things.

Further reading

• FullScale summary of GitHub research on focus: https://fullscale.io/blog/engineering-productivity-paradox/
• Clockwise meeting benchmarks: https://www.getclockwise.com/eng-meeting-benchmarks
• TeachingAgile on WIP limits: https://teachingagile.com/kanban/introduction/kanban-wip-limits
• Planview Flow Framework (flow metrics): https://info.planview.com/rs/456-QCH-520/images/flow-metrics-business-leader-guide_ebook_rbd.pdf
• DORA 2025 report: https://dora.dev/research/2025/dora-report/
• arXiv: Measuring AI impact on developer productivity (2025 study): https://arxiv.org/html/2509.19708v1

Your Team's Work, Translated for Leadership. Automatically.

We're announcing a feature that changes how teams communicate progress: AI-powered weekly updates that write themselves based on the work you're already doing in GoalPath.

No extra reporting. No status meetings. No manual writeups.

Just clear, consistent, trustworthy updates, every week, automatically.

The Problem: Status Updates That Waste Everyone's Time

If you've ever spent an hour writing a status update, or sat through a meeting where someone reads through Jira tickets, you know the pain:

• Teams spend hours writing updates instead of building
• Executives ask "what's actually happening?" because status updates are vague or overly optimistic
• Critical issues hide in disconnected tools and Slack threads
• Nothing is consistent week to week: format changes, detail level varies
• Onboarding new stakeholders means digging through chat history or scheduling more meetings

The traditional solution? More meetings. More slides. More manual work.

We built a better way.

How It Works: Work As You Normally Do

The key is that you don't change how you work.

1. Your Team Works in GoalPath

You're already creating and completing items, moving work through milestones, flagging blockers, and tracking dependencies. GoalPath captures all of this as it happens. No extra steps.

2. Weekly Summaries Generate Automatically

Every Sunday evening, GoalPath looks at each active milestone and creates a focused summary:

• What was delivered this week (with enough context so stakeholders understand the value)
• Active blockers or concerns (only if significant, no noise)
• One actionable insight for what to focus on next week

These summaries are grounded in real data: completed work items, activity history, unresolved highlights, current in-progress work, upcoming items, and past 4 weeks of context for pattern recognition.

If a milestone had no activity, the summary says so clearly. No fake updates, no spin.

3. Project Updates Aggregate Everything

All milestone summaries roll up into a single, coherent project-level weekly update structured for leadership:

Overview: What materially changed this week, current delivery outlook, and one focus item for leadership attention.

Metrics: Velocity, completion rates, active blockers, work in progress. Factual data, no interpretation.

Milestone Progress: A clear synthesis of each milestone's status: what moved forward, what's blocked, what changed since last week.

Upcoming Milestones Forecast: Data-driven delivery forecasts showing best case, expected, and risk-adjusted completion dates for in-progress and upcoming milestones. Grouped by team with active blockers highlighted.

Looking Ahead: What to watch next week, known dependencies, and any decisions that need to be made.

The whole update is 400-600 words, concise enough for busy executives to scan in 2-3 minutes, detailed enough to actually understand what's happening.

4. You Stay in Control

Critical point: The AI drafts. You decide.

Every update is fully editable before it's shared. If the AI missed context, add it. If the tone isn't quite right, adjust it. If you want to emphasize something, do it.

All edits are tracked, so there's a clear record of what was AI-generated and what was human-refined.

Why This Works: Evidence Over Opinion

Traditional status reporting has a trust problem: it's based on what people say is happening, not what's actually happening.

GoalPath's weekly updates are different:

When leadership asks "what's happening with Project X?", they get a factual, consistent narrative with data-driven delivery forecasts, not political spin or someone's best guess.

Real Benefits for Your Team

For Individual Contributors

• No status report homework: your work speaks for itself
• Credit for what you delivered: completed items show up with context
• Blockers get visibility: highlights you flag reach leadership automatically

For Team Leads and Project Managers

• Reclaim 3-5 hours every week: no more writing status decks or synthesizing Jira exports
• Consistent communication: same structure, same quality, every single week
• Historical record: see patterns over months. Are issues recurring? Is velocity trending?

For Executives and Stakeholders

• Clear signal over noise: one concise update per project, per week
• Data-driven forecasts: see 3-point delivery estimates, not just "on track"
• Earlier risk detection: issues surface in writing before they become critical
• No more status meetings: read updates asynchronously, ask questions in context
• Onboard new stakeholders instantly: historical updates create perfect context

For Everyone

• Trust: updates are evidence-based, not opinion-based
• Time: less time reporting, more time building
• Clarity: shared understanding of what's happening across the organization

Multi-Language Support

GoalPath supports 8 languages with consistent, proper terminology:

• English
• Swedish
• Danish
• Norwegian
• German
• French
• Spanish
• Italian

Updates are generated in your project's language with proper terminology, not just translated, but written naturally from scratch.

Holiday Awareness

The system knows when holidays might affect velocity (Christmas, Easter, New Year's, etc.) and provides this context in updates so stakeholders understand why activity might drop without raising false alarms.

Getting Started

For new projects: Weekly updates are enabled by default. Just work as normal, and your first update will generate automatically on Sunday evening.

For existing projects: Navigate to your project settings and configure your preferred language and default recipients.

Editing updates: After generation, you'll see a draft in your project dashboard. Review it, make any edits, then click "Send" to share with stakeholders via email.

Backfilling history: Want to generate updates for past weeks? Use the "Generate Historical Updates" option in project settings to backfill up to 12 weeks of history.

Why We Built This

We believe teams should spend time building, not reporting.

But we also believe leadership needs clarity to make good decisions.

The tension between these two needs has created an entire industry of status meetings, slide decks, and manual reporting work that everyone hates.

AI makes it possible to resolve this tension: Automatic, trustworthy, evidence-based communication that requires zero extra work from teams.

This is what "AI-assisted product management" should look like: invisible, helpful, and genuinely time-saving.

Try It Today

Automated weekly updates are available now for all GoalPath users.

New to GoalPath? Start your free trial and see your first weekly update generated automatically.

Questions? Email us at support@goalpath.app or check out our documentation.

Velocity is the engine behind GoalPath's forecasting. It measures your team's actual delivery speed and uses that data to predict when future work will be done. No guessing required.

What Is Velocity?

Velocity is how many story points your team completes per work-week (Monday through Friday). GoalPath calculates this automatically from completed work items.

Velocity = Story Points Completed / Work-Weeks

For example, if your team completes 45 story points over the last 6 weeks, your velocity is 7.5 points per work-week.

Why work-weeks? Calendar weeks include weekends, which would overestimate every forecast by nearly 29%. Work-weeks give you realistic timelines based on when work actually gets done.

Why Velocity Matters

Velocity serves two purposes:

1. Understand capacity: How much work can your team realistically complete in a week?
2. Forecast delivery: When will a milestone finish based on current pace?

How GoalPath Calculates Velocity

GoalPath looks at the last 6 weeks of completed items (items that reach "Accepted" status):

• Sums story points delivered each week
• Calculates the average velocity
• Tracks standard deviation to understand consistency

Consistency matters. A team that delivers 10 points every week is more predictable than one that swings between 5 and 15. GoalPath uses standard deviation to widen or tighten forecast ranges accordingly.

What Makes GoalPath's Forecasts Different

Velocity alone gives you a baseline. GoalPath goes further with three additional factors:

Multitasking Penalties

Context switching destroys productivity. When team members juggle multiple milestones simultaneously, GoalPath applies empirically-derived penalties:

• 1 concurrent milestone: No penalty (100% effective)
• 2-3 milestones: 15% penalty (85% effective)
• 4-7 milestones: 30% penalty (70% effective)
• 8+ milestones: 50% penalty (50% effective)

This prevents over-optimistic forecasts when your team is spread thin.

Confidence Levels

Not all work is equally predictable. GoalPath supports three confidence levels per milestone:

• High (90%): Well-understood work, clear requirements (10% buffer)
• Medium (75%): Some unknowns, moderate complexity (25% buffer)
• Low (60%): Exploratory work, many unknowns (50% buffer)

Lower confidence means wider forecast ranges, because honest uncertainty beats false precision.

Uncertainty Propagation

GoalPath combines multiple uncertainty sources (unestimated items, velocity variance, confidence level, and team coordination) into a total uncertainty multiplier. This produces three scenarios:

• Optimistic: Everything goes better than expected
• Expected: Most likely outcome including reasonable buffers
• Pessimistic: Accounts for delays, blockers, and scope creep

The result is a forecast range, not a single date. Because the future is uncertain, and your forecasts should reflect that.

Delivery Probability Lines

When viewing items in a milestone, colored lines appear between items showing delivery thresholds:

• Green: Best case, what you'll likely deliver at optimistic velocity
• Amber: Probable, based on median velocity
• Red: Worst case, at pessimistic velocity

These help you prioritize: anything above the green line for your target week is highly likely to ship. Items below the red line need reprioritization or scope reduction.

Improving Your Forecasts

Want tighter ranges and faster delivery?

1. Reduce multitasking: Focus team members on fewer concurrent milestones
2. Estimate all items: Each unestimated item adds uncertainty
3. Build consistent velocity: Reduce WIP, address bottlenecks
4. Increase confidence: Spike on unknowns before committing

Common Questions

"Our velocity varies a lot. Is that normal?"

Yes. Real teams have natural variance. That's why GoalPath uses three-point estimation with uncertainty propagation instead of simple linear projections.

"Should we try to increase velocity?"

Velocity is a measuring tool, not a target. Artificially inflating velocity (marking things done early, breaking items smaller) makes forecasts less accurate, not better.

"What if we don't use story points?"

Progress reports work with item completion tracking. Forecasts are most accurate with story points, but GoalPath provides useful predictions based on execution order even without them.

Next Steps

• Understanding Project Forecasts: Deep dive into the math behind forecasts
• Visual Roadmap: How dependencies and goal paths shape delivery
• Automated Progress Reports: How velocity data powers weekly updates

Most teams don't fail due to lack of execution. They fail because stakeholders and teams talk past each other. Progress gets interpreted, not shared.

We built GoalPath to fix that.

The Problem

Traditional project management tools are blank canvases. You set up Jira, then spend weeks documenting "how we use Jira" on Confluence. You build a roadmap in a spreadsheet, and it's outdated by Monday. You spend Friday afternoon writing the same status update you wrote last Friday.

Meanwhile, stakeholders keep asking "where are we?" because they don't trust the green dots on your dashboard.

The real cost isn't the tool. It's the process tax around it.

A Different Approach

GoalPath embeds lean delivery expertise directly in the product. No separate documentation. No "how we work" wiki. No consultants.

1. Automatic Progress Reports

Every week, stakeholders get plain-English progress reports generated from your team's actual work:

• What shipped: completed items with context stakeholders can understand
• What's blocked: active blockers flagged automatically
• Forecast changes: "Launch moved 3 days, now Feb 14"
• What needs attention: risk-adjusted delivery dates with confidence ranges

Time to create: 0 minutes. Reports generate automatically every Sunday night, ready for Monday morning.

This isn't reporting. It's shared reality.

2. Data-Driven Forecasts

Instead of guessing "when will this be done?", GoalPath calculates it from your team's actual velocity:

• 3-point estimates: Best case, expected, and risk-adjusted completion dates
• Confidence-aware: High, Medium, or Low confidence shapes uncertainty buffers
• Multitasking penalties: Accounts for the real cost of context switching
• Dependency-aware: Forecasts respect what's blocking what

Forecasts update automatically as work completes. No spreadsheet math. No guessing.

3. Process Built Into the Interface

GoalPath guides you through the right workflow: the interface shows you what to do next and why. Alignment meetings have built-in stages. The roadmap shows dependency flow toward goals. Prioritization uses proven frameworks (RICE, Impact/Effort, MoSCoW, or weighted scoring).

Result: No training docs. No process documentation. Just open GoalPath and follow the interface.

4. Roadmaps That Actually Navigate

Traditional roadmaps are wishful timelines. GoalPath roadmaps show the dependency flow toward business goals:

• Reverse plan from outcomes back to current work
• See the critical path and bottlenecks at a glance
• Goal paths highlight what you're committed to vs. what you're exploring
• Forecasts update as the roadmap evolves

Roadmaps become navigation tools, not decorative timelines.

Who It's For

GoalPath is built for teams with 5-20 engineers, where everyone still knows each other but stakeholders are starting to ask "where are we?" multiple times per week.

• Product Owners & PMs spending hours on status updates
• Tech Leads & CTOs who want stakeholder visibility without interrupting their team
• Founders who realize spreadsheets won't scale past 5 engineers

Getting Started

1. Create Your Project: set up your first project and invite your team
2. Add Milestones: define key deliverables and connect dependencies
3. Track Velocity: complete work items to build your baseline
4. Review Forecasts: see realistic delivery dates with confidence ranges

The Bottom Line

Replace 3-5 hours of status meetings per week with one automated update that takes 0 minutes to create. Your team ships. Your stakeholders stay informed. Zero meetings required.

Get started with GoalPath today →