Operations & PM Teams

Manual Cycle Time and Velocity Tracking (No Jira, No Budget)

You can measure velocity and cycle time accurately for your sprint reviews with just a spreadsheet and 15 minutes per sprint–no need for extra tools or budget. Here"s a simple, battle-tested method that works even if your team"s stuck in Trello.

Georg Singer·June 9, 2026·16 min read

Manual Cycle Time and Velocity Tracking (No Jira, No Budget)

You"re sitting in your sprint review. Someone asks, "So… what was our velocity this sprint?" You crack open your Trello board, count cards in your head, toss out a number. It"s ballpark. But deep down, you know it"s not right–half the cards are still "In Progress," and you have no clue when any of them actually started.

Sound familiar? You"re not alone. Trello doesn"t track flow metrics out of the box–velocity gets guessed, action items disappear after the review, and cycle time is just a rumor. That"s the "retro-to-sprint gap" in action.

But here"s the good news: You can fix all this with a spreadsheet formula and 15 minutes per sprint. No new tools, no budget, no begging IT for licenses. By the end of this article, you"ll have a working tracking setup and a 10-minute sprint ritual that"ll give you more actionable data in three months than most Jira teams ever see.

Quick takeaways: > - Note the start date when a task actually begins–this is your only technical must-have.

=NETWORKDAYS(start, end) calculates cycle time in workdays, skipping weekends.

For ops teams without story points, just count completed tickets per sprint for velocity.

Pick a method and stick with it for at least 6 sprints–consistency beats precision every time.

50% of PMs spend at least a day a month merging status updates manually (ProProfs, 2024). This setup solves exactly that headache.

What"s the Real Difference Between Cycle Time and Velocity?

Ever been lost in a meeting where everyone mixes up cycle time and velocity? Happens all the time–and if you track the wrong thing, your metrics become meaningless.

Let"s cut through the jargon:

Cycle time is the number of workdays a task spends from the moment you actually start work to the moment you call it done. It"s not about how hard the task was–it"s about how predictable your delivery is.
Velocity is how much work your team finishes per sprint. If you"re not using story points (and most ops teams shouldn"t bother), it"s typically just the number of tickets or hours completed. But here"s the catch: Velocity only matters as a trend over 4–6 sprints. One value is just noise.

The key distinction? Cycle time is about each individual task. Velocity is about the whole sprint. They"re both crucial, but need different data–and both start with the same thing: a start date.

If you"re an ops team, ticket count works just like story points–without all the estimation meetings. Don"t let anyone convince you otherwise. Sure, a planned bug fix isn"t the same as a surprise stakeholder request–but if they"re roughly the same size, counting them is enough.

Let"s put this in perspective. According to the Asana Anatomy-of-Work-Index, knowledge workers spend 60% of their time on "work about work"–chasing status, switching apps, duplicating reports, endless meetings. Only 27% of their time goes to real, skill-based work. By tracking cycle time and velocity, you flip that script: you see what actually gets finished, not how much coordination it took to get there.

And here"s the kicker: A single velocity number is useless. Know your velocity after Sprint 1, and you have a number. Know it for six sprints, and you have the beginnings of actual capacity planning.

Now that you"ve got the basics, let"s see why so few ops teams actually track these numbers.

Why Don"t Ops Teams Track Cycle Time and Velocity More Often?

Imagine this: 70–80% of all action items from retros never get implemented. Seriously. Dejan Majkic found that it"s the same problems, same sticky notes, same people–sprint after sprint–without real change. Action items get dumped into Trello, never to be seen again.

Is it laziness? Lack of time? Not really.

According to ProProfs" 2024 Workflow Automation Statistics, half of all PMs already waste a full day every month just merging manual status updates. So the time is there–it"s just getting burned on the wrong problem.

The real culprit? Structural blind spots. Trello, for example, doesn"t log when a task starts unless you"ve set up a Butler automation or similar. So PMs end up guessing velocity instead of measuring it. Those guesses drift over time. The errors never get exposed.

It gets worse. Most ops PMs know what cycle time and velocity are. The missing link isn"t the tool–it"s the moment you capture the data. This isn"t a discipline problem. It"s a workflow gap.

Here"s how one Redditor summed it up: "I feel overwhelmed by our over-dependence on SaaS."

– r/SaaS, Score 57

Think about that. The irony is, manual tracking problems often come from having too many tools–and none of them answer your actual questions.

Let"s compare:

Before: Sprint review, Sprint 7. Velocity: "Maybe 12 tickets?" Cycle time: unknown. Stakeholder asks, "How predictable are we?" You guess.

After: Sprint review, Sprint 7. Velocity: 11 tickets (8 bugs, 2 features, 1 request–9 planned, 2 unplanned). Average cycle time: 3.4 workdays. Two tickets took over 7 days–both unplanned, both delayed by external dependencies. Now you"re not just guessing–you"re running on operational intelligence, not data junk.

And the difference? It"s not a fancy tool. It"s a 2-minute ritual at the start of every sprint.

Let"s see exactly how you can do it.

Step 1: How to Track Cycle Time Manually–The Minimal Setup

How do you measure cycle time without Jira or a specialized tool? Here"s the simplest process that works:

When a task starts, note the date. Could be a comment, a custom field, or a date property–whatever works in your system.
When the task is done, record the end date.
Calculate the cycle time using =NETWORKDAYS(start, end). This gives you the number of workdays (excluding weekends).

A Google Sheet with five columns is all you need for tracking over multiple sprints.

Let"s break it down with examples:

Trello: Add a comment like Started: 2026-03-15, or use a custom field (there"s a free Power-Up for that).
Notion: Use a date property directly in your task database.
Linear: The built-in "Started" field makes this trivial.

The formula:

Cycle Time = =NETWORKDAYS(Start Date, End Date)

NETWORKDAYS gives you workdays, not calendar days. So if a task starts on Friday and finishes on Monday, the cycle time is 2–not 3. This matters because most ops teams don"t work weekends.

Here"s the process in action:

Task created
  → Task starts (record date, right away)
  → Task finished (record date)
  → Calculate cycle time: =NETWORKDAYS(start, end)
  → Add to spreadsheet
  → Review once per sprint

Here"s what your tracking sheet should look like:

Task Name	Started	Completed	Cycle Time (days)	Category
Login Bug Fix	2026-03-10	2026-03-12	=NETWORKDAYS(B2,C2)	planned
Stakeholder Report	2026-03-11	2026-03-18	=NETWORKDAYS(B3,C3)	unplanned

⚠️ Heads up: Cycle time tells you how long a task took from start to finish–not how much work it was. If a task sat "In Progress" for 8 days because no one touched it, its cycle time is 8. That"s not a dig at your team–it"s valuable information: the task shouldn"t have started until capacity was available. That"s how flow metrics become operational intelligence–not performance policing.

One more thing: If you don"t record the start date when work begins, you"ll never reconstruct it reliably. The date field has to be part of your workflow–not an extra step in another app. According to the Lokalise Tool Fatigue Report 2025, employees switch apps an average of 33 times per day. Every extra app switch kills adoption.

Now you know how to track cycle time. But how do you measure velocity if you don"t use story points?

Step 2: Velocity Without Story Points–Three Practical Methods

How can you calculate velocity if your team never estimates story points? Here"s the lowdown:

The simplest way: Just count the number of tickets that moved from "In Progress" to "Done" this sprint. This only works if your tickets are all about the same size. If not, split by category and track velocity for each.

For ops teams, you have three practical options:

Method	Prerequisites	Effort per Sprint	Precision	Recommended Team Size	When to Switch
A: Ticket Count	Tickets about the same size, clear "Done" definition	5 min	Good enough	3–15 people	If ticket sizes vary a lot
B: Hours-Based	Team already logs hours worked	15 min	High	5–25 people	If hour tracking becomes too much
C: T-Shirt Sizes	Team already estimates S/M/L	10 min	Medium	5–20 people	Only if system is established

Here"s how T-Shirt sizing works: S = 1 point, M = 3 points, L = 8 points. Just total up the points. No extra estimation meetings needed–T-Shirt sizing can be done in two minutes at the start of the sprint.

Let"s put it in context. According to Plaky PM Statistics 2026, 75% of project managers say they have too much work and too few resources. Velocity is the only way to turn that feeling into numbers: "We complete 11 tickets per sprint, but you"ve loaded us up with 18" is a much more productive conversation than "we feel overloaded."

Biggest mistake? Switching methods between sprints. If you track Sprint 1 by ticket count and Sprint 2 by hours, your data is garbage. Velocity trends only mean something if you"re consistent. Pick a method–stick with it for 6 sprints. Consistency beats precision in trend analysis.

So you"ve got your method. Next up: building your tracking sheet.

SwiftRun automates repetitive workflows with AI agents – so your team can focus on what matters.

Try Free Book a Demo

Step 3: Build Your Sprint Tracking Sheet–Copy This Template

You only need two tabs: "Data" and "Analysis."

Tab 1: Data–8-Column Structure

Sprint	Task Name	Type	Started	Completed	Cycle Time	Velocity Unit	Note
Sprint 12	Login Bug	Bug	2026-03-10	2026-03-12	=NETWORKDAYS(D2,E2)	1	API dependency
Sprint 12	Onboarding Flow	Feature	2026-03-09	2026-03-16	=NETWORKDAYS(D3,E3)	1	Waiting on design

Tab 2: Analysis–Three Formulas You Need

## Average cycle time for Sprint 12
=AVERAGEIF(A:A, "Sprint 12", F:F)

## Velocity (all completed tickets in Sprint 12)
=COUNTIFS(A:A, "Sprint 12", E:E, "<>")

## Velocity (only planned tickets)
=COUNTIFS(A:A, "Sprint 12", C:C, "planned", E:E, "<>")

Want a trend over six sprints? Use one AVERAGEIF per sprint in a summary row. You"ll get a trend chart for your sprint review–no fancy dashboards required.

The 10-Minute Sprint-End Ritual:

Open your sheet–go to the Data tab.
Enter all tasks completed this sprint (start dates should already be there).
Switch to the Analysis tab: read off average cycle time and velocity for this sprint.
Write one observation: "Cycle time rose from 3.1 to 4.7–three unplanned tasks, all delayed by external review."
Add that number and observation to your sprint review doc.

My experience: > The sheet isn"t the point–the ritual is. If you fill out your sheet after each sprint and write the numbers into your review doc, you"ll have more useful, interpretable data after three months than most Jira teams ever get. Jira gives you burndown charts. This sheet tells you exactly why your cycle time spiked in Sprint 10.

⚠️ Warning: Never share this sheet as a performance monitoring tool with stakeholders until you have 4–6 sprints of baseline data. A single-sprint value is just statistical noise. Velocity is for planning, not benchmarking. Using velocity to compare teams destroys psychological safety–this isn"t just an opinion; it"s one of the few things all agile practitioners agree on.

So, you have the structure. But what could go wrong? Let"s audit your setup before you start.

The 3 Most Common Mistakes in Manual Velocity Tracking

Three mistakes can ruin your setup. Only the first is truly fatal–the other two are manageable as long as you know to watch for them.

Mistake 1 is the killer: If you miss recording start dates, you can"t calculate cycle time. No amount of guessing can fix this–memories fade, estimates turn into wishful thinking, and your data becomes useless.

The fix isn"t discipline–it"s workflow design. The date field needs to pop up when the task starts. Not after you switch apps.

Set a board rule. In Trello: "No card moves to "In Progress" without a date comment." In Notion: make the date property required. A simple Monday morning Slack reminder–"Did anyone start tasks today? If so, add the start date"–has kept more teams on track in my experience than any new tool.

Mistake 2 is less dramatic but just as sneaky. If you track Sprint 1 by ticket count and Sprint 2 by hours, you might have data–but not comparable data. That"s like tracking your weight in kilograms one week and pounds the next, then plotting the trend.

Mistake 3 is a conceptual one: If a task"s cycle time is 12 days, that doesn"t mean 12 days of work–it just means it sat around for 12 days. That"s valuable information, but you need to understand it before you report the number.

Here"s a 5-point checklist for your setup audit before Sprint 1:

Every task tool has a start date field or a clear note convention that everyone knows
"Done" is defined in writing for all task types, and everyone uses it
Your velocity method (A, B, or C) is picked and locked for at least 6 sprints
Your sheet is set up with NETWORKDAYS and COUNTIFS formulas–test it with three tasks before sprint start
The sprint-end ritual is booked as a fixed 10-minute block in your sprint review meeting

If you check these five boxes before Sprint 1, you"ll have a working flow-tracking system. Not perfect–but accurate enough for real operational decisions.

When Should You Switch From a Spreadsheet to a Tool?

Manual tracking works for ops teams up to about 15 people, for 6–12 months, with no pain. You only need to upgrade when:

You"re juggling more than three parallel projects and manual aggregation gets painful,
Stakeholders demand real-time dashboards instead of a summary every two weeks, or
Maintaining the sheet eats up more than 30 minutes per sprint.

Here"s some context: Ops teams at SaaS companies with 50–200 employees use an average of 87 different tools–and still lack a single source of truth. According to the Spendflo SaaS Sprawl Report, 87% of companies say this SaaS sprawl has a moderate to severe financial impact. And 53% never see the expected ROI from their software (Freshworks Cost of Complexity Report 2025). That"s not an argument against buying tools–it"s an argument for proving value manually first.

The crazy thing is, almost every tool tracks velocity, but hardly any tell you why your velocity dropped. That"s the real gap.

Here"s a quick comparison of your options:

Tool	Type	Price (approx.)	Strength for Ops Teams	Limitation
Screenful	Trello Add-on	€27/mo ($29)	Native cycle time from Trello data	Shows data, doesn't interpret–analysis is up to you
Linear	PM Tool	from €7/user/mo ($8)	Built-in cycle time (if you already use it)	Requires switching off your current tool
SwiftRun.ai	Automation	–	Reads Trello data directly, no export needed	Only worth it after you"ve proven tracking value

Sure, you could pay €27/mo for Screenful. But here"s the thing: Manual tracking forces you to notice every anomaly. If you track six sprints yourself, you"ll understand your data. Jump into a reporting tool after Sprint 1, and you"ll get numbers–without context.

Want to scale this up? SwiftRun.ai can read your existing Trello board and calculate cycle time and velocity automatically–no manual export, no per-sprint setup. But don"t jump in until you"ve proven the value with real data.

What"s Your Next Step? (And What Comes After That)

Here"s what you should do today:

Create your sheet.
Enter the last five completed tasks with estimated start dates (okay for baseline).
Start your next sprint with a board rule for start dates.
After three sprints, you"ll have your first reliable numbers for a data-powered sprint review.

Curious how to spot recurring themes in your retros? Or why flow metrics are structurally missing from most PM tools for ops teams? Watch for the next articles in this series.

Further reading: How to spot recurring issues in your retrospectives (coming soon)

Frequently Asked Questions

How do I calculate cycle time without a specialized tool?

You just need to note the start and end dates for each task and use the =NETWORKDAYS(start, end) formula in a spreadsheet. This gives you the cycle time in workdays, not calendar days. Make it part of your workflow by requiring a start date when tasks move to "In Progress."

What"s the best way to measure velocity if I don"t use story points?

The fastest, lowest-friction method is to count the number of tickets completed in each sprint–if your tickets are similar in size. If not, try T-Shirt sizing (S/M/L) or hours worked, but keep your method consistent for at least six sprints to build a meaningful trend.

What"s the most common reason manual tracking fails?

The biggest failure point is missing start dates. Without them, you can"t calculate cycle time reliably. Solve this by embedding the start date field directly into your workflow–don"t leave it as an afterthought or a separate app.

When does it make sense to switch to a specialized tool?

Move to a dedicated tool when manual aggregation takes more than half an hour per sprint, or when you need real-time dashboards for multiple projects. Always prove the value of tracking manually first–most teams don"t get the ROI from fancy tools until their process is solid.

Does cycle time track effort?

Cycle time measures elapsed workdays from start to finish–not the effort or complexity of a task. A task that sits untouched for 8 days has a cycle time of 8, even if no one worked on it. Use this to spot bottlenecks, not to judge individual performance.

Ready to ditch the guesswork and actually know your team"s velocity? Start with a sheet. Stick with the ritual. In three months, you"ll have data most teams only dream of.

"Feeling overwhelmed by our over-dependence on SaaS."

– r/SaaS, Score 57

Asana estimates that knowledge workers could reclaim 4.9 hours per week through better processes–over six workweeks a year. A 10-minute ritual per sprint is your fastest path there.

Related Articles:

Ready to ditch the spreadsheet struggle and get clear insights into your team's workflow without breaking the bank? Check out SwiftRun.ai to start tracking your cycle time and velocity effortlessly.