Timeline Dashboard what it was, and what comes next.

Short answer: Pivotal Tracker was an opinionated agile project tracker built around iterations, story points, accepted-stories velocity, and a single prioritised backlog. VMware shut it down on April 30, 2025, after seventeen years. The product mattered because it forced one prioritised list, one owner per story, and a velocity that only counted shipped value. Most modern tools let you cheat all three. If you still have data in there, export it now and move to a Tracker-style tool rather than a Jira-style one.

Pivotal Tracker is no more. Tanzu will end on April 30, 2025, after a 17-year run at VMware. If you searched for the name on Google the last two years, you got a tool that was stripped down to Enterprise-only, then sunset completely, then archived. That’s everything worth knowing. You can stop reading this.

Chances are you won’t. Most people searching for that phrase are either trying to recall how the workflow functioned, trying to evacuate their data, or trying to find something Tracker-shaped to replace it with. We’ll cover all three.

If you are an engineer, anchor, or founder who has used Pivotal Tracker, inherited a backlog from someone who did, or who keeps getting told by a senior dev to run things “the Pivotal way”, then this guide is for you. In this blog, we will look at what Pivotal Tracker actually was, how the workflow worked, why it was shut down, what to do if you still have a project in there, and what things the analogue replacements get right and wrong.

LiteTracker is based on the same ideals Pivotal Tracker was based on, and that’s not a disclosure after the fact. Velocity based on iterations, story points, and accepted stories. We will discuss the comparison later. For now, the backstory.

Pivotal Tracker, plainly explained

Pivotal Tracker is a story-based project management tool conceived at Pivotal Labs with public launch in 2008. It was targeted mainly at agile software teams, specifically teams running XP-flavoured agile in the spirit of the Agile Manifesto rather heavy-process Scrum, and the design choices made that bet explicit.

The Form

• One prioritised backlog per project. Not many. One. The team's job was to pull the top story.
• Stories estimated in points, not hours. The scale was small, usually 0–3 or 1, 2, 3, 5, 8.
• Velocity calculated automatically as a rolling average of accepted stories per iteration. The team didn't enter it. Nobody could fudge it.
• Iterations auto-allocated based on velocity. You didn't sprint-plan into a Gantt chart; the tool packed stories into the next iteration column until it ran out of room. The cadence question of how long an iteration should run was settled once per project, not relitigated every quarter.
• Three card types (feature, bug, chore), and only features earned points. Bugs and chores were tracked but didn't inflate velocity.

That's the core. Tracker's foundation was based on five key rules. Additional features such as labels, epics, releases, and integrations were then added on top of that base. However, it was those five rules that truly defined Tracker as a Tracker and not a Jira.

In 2019, VMware renamed Pivotal Labs (now known as VMware Tanzu Labs). Subsequently, Broadcom sold VMware (in 2023). After each event, the tracker survived! Until it didn’t.

How Pivotal Tracker actually worked

The smallest chunk of work which is delivered is the story, a piece of user-facing value in a narrative form. Not a task. This isn't a technical issue. A narrative

In this order, each story transitioned through five states.

1. Start — an engineer claims the story and begins work.
2. Finish — the code is done and merged.
3. Deliver — the story is deployed to a place where the product manager can see it.
4. Accept — the PM looks at it, decides it does what the story says, and clicks Accept.
5. Reject — or the PM looks at it, decides it doesn't, and the story comes back.

The not-so-obvious aspect is step 4 when the velocity isn't updated when work is completed. It updated each time work got accepted. The team might produce a hundred lines of code in an iteration. If the PM hadn’t pressed Accept on a single story, though, that iteration’s velocity was zero. The action was intentional. The project manager was obligated to view the outcomes of the work. The team was then made to chase finished, accepted stories rather than in progress theatre.

The stories were arranged in one of the three columns.

• Current iteration — what the team is working on this two weeks. Capped by velocity.
• Backlog — what's coming next, ordered top-down by priority. Keeping that list clean is its own discipline — see how much backlog refinement is actually useful.
• Icebox — everything that's been suggested but not yet committed to. Unordered.

Useful. User can drag a story up the backlog to bring it into the current iteration, and the tool automatically pushed lower stories down, or out, based on the velocity cap. A Gantt chart was absent. There is no resource leveller. A roadmap module wasn’t present. It was argued that those things hide more than they show.

This tool came with an epics layer that allowed users to group related stories, a labels system, releases as milestone markers, and the usual suspects (GitHub, Slack, Zapier). The workflow explained above is what made Pivotal Tracker recognisable.

The deliberate constraints that made it different

The unique thing that Pivotal Tracker offered wasn't a feature at all. The tool had a list of things that it wouldn’t let you do.

You were unable to.

• Assign more than one owner to a story. One human, one card. The handoff conversation was forced to happen on the card itself, not in private.
• Have multiple "current" iterations. Only the top of the backlog was committed.
• Estimate stories in time. Points only — closer to Atlassian's framing of relative estimation than to hour-based forecasting.
• Count bugs or chores toward velocity. Recovery work didn't inflate forecasts.
• Build a custom workflow with seventeen states. The five states were the five states.
• Hide the prioritised list. There was always exactly one ordering of stories from top to bottom.

For a Jira admin, this list is a big feature gap. This list seems perfect according to every user using tracker for more than year to run their team.

It was wagered that the practice was the limitation. The imposition of a singular prioritised backlog obliged the product manager to take a decision every day on the next most important thing to do and not just run a planning meeting where everyone aligned on a quarterly theme. The restriction on one owner per card implied a story couldn’t be dropped without discussion. Only accepted stories could count towards momentum, which made it impossible to fake one’s way through an iteration with half-done work. It wasn't attempting to accommodate all workflows. It was attempting to enforce a single-type workflow, yes.

Why teams loved it (and why some didn't)

Teams who loved Pivotal Tracker, tended to love it for similar reasons. The restrictions led to the visibility of the job. The velocity metric was legitimate. The product manager's duty was to perform the PM job. A story can no longer hide; it can’t be dumped into a kanban swimlane; it can’t be parked in “blocked” status for three iterations. Tracker had a famously deadpan attitude towards progress: a story was either accepted or it wasn’t. The reason given in the first sentence of this paragraph is that reviewers at Capterra describe LiteTracker, which will inherit the same opinion, as “something which XP/Scrum practitioners love”.

The teams that hated it shared similar reasons for doing so. An absence of a Gantt chart meant nobody could speak straight to a senior stakeholder and promise a date. The absence of a customized field for department, epic owner, and OKR alignment prevented the tool from serving as a reporting tool. As the story states were fixed, teams who were running QA in a separate org couldn't map their wares to the tool without bending it.

It is only fair to say that most of these complaints were about the methodology. Tracker utilized agile flavoring with a scant feedback loop, which the tool blatantly refused to disguise itself as. The tool would not be adaptable if your organization wasn't utilizing XP-flavoured agile.

The lesson we are able to draw most clearly by now with the Tracker era is the following: **most teams who left Jira for Tracker stayed; most teams who left Tracker for Jira drifted back, and those that didn’t generally drifted out of agile altogether.**Note that above is not a tools argument. This is a discipline argument. Jira allows you to dodge the discipline. Tracker shall not.

Why Pivotal Tracker shut down

A Brief History.

• 2008 — Pivotal Tracker launches at Pivotal Labs, a consultancy that taught XP to enterprises.
• 2019 — VMware buys Pivotal Labs. The tracker product becomes part of VMware Tanzu Labs.
• 2023 — Broadcom buys VMware. The Tanzu portfolio enters the standard post-acquisition review.
• March 31, 2024 — VMware discontinues the Startup and Standard plans. Tracker becomes Enterprise-only.
• September 18, 2024 — VMware announces full end-of-life for Pivotal Tracker, effective April 30, 2025.
• April 30, 2025 — The service sunsets. Customers are told to export their data by that date or lose it.

The Broadcom Playbook is no longer a mystery. Obtain, segment by income, discontinue those that do not meet the enterprise margin threshold. Pivotal Tracker’s real-world evidence from tiny use-cases makes them sure that hundreds of thousands of remote teams use it. That calculation won't pass a Broadcom examination.

When a piece of software receives the wrong ownership, good software can quickly deteriorate. Most tools today live inside a company whose business strategy can change overnight. This carries the same risk for most tools.

What to do if you still have data in there

Did not export from your Pivotal Tracker project? Don’t worry; that data is gone. Everyone suffered from the shutdown. After April 30, 2025, nothing can be recovered from VMware.

You have options if you have an export from prior to April 30, typically a CSV or XML dump.

1. Sit on it. Most projects' history is more useful as a record than as something to keep editing. A CSV in git is a reasonable place to put it.
2. Import it into a Tracker-shaped tool. A handful of tools built CSV importers specifically for Pivotal Tracker exports, because they expected this exact migration. The import is fast (LiteTracker's is a one-minute upload), and the field mapping is close to 1:1 for stories, points, states, and labels.
3. Re-platform onto Jira / Linear / monday. Doable, but each of these tools wants different fields. Expect to lose state mappings, the iteration cadence, and the accepted-only velocity. The tool will work; the practice will silently get worse.

If you're down to choosing between option 2 and option 3, then the honest question is: did Tracker's opinions match yours, or did you just use Tracker because someone else selected it? If that is the case, select a Tracker-shaped successor. If this is the scenario, then you have more choices.

What Pivotal Tracker got right that most modern tools miss

Jira won the tool layer of agile partly because it would be palatable to enterprises, but also because it would bend to whatever process you threw at it. The niche success of Tracker was its refusal to scale.

Three things Tracker got right, unlike modern project management tools.

The prioritised list of stories is Tracker. Thus, there is one order from top to bottom for all stories in scope. It was the responsibility of PM. Most modern tools support multiple parallel boards, kanban lanes, dependency graphs, and priority labels. This is just a long-winded way of saying they support you in never deciding what's next. When the tool abolishes the forcing function, the tactic rots.

Velocity should measure accepted stories and not committed stories, as the former is a better indicator of value delivered. Velocity in other tools refers to a forward-looking commitment, where the team strategizes based on it and then pursues the goal. The two practices may appear similar but yield opposing cultures.

Tracker doesn’t support adding a status report, or a roadmap module, or an executive dashboard to it. The tool was designed to assist the team with shipping. Another person was responsible for the reporting. Most modern PM tools have developed a reporting surface so gigantic that the working-team workflow now lives inside it as a small subset, with the remainder marking the screenshot that goes into the QBR deck.

This is subjective. According to most reviews for agile tools, the “best tool” must have the maximum number of features. The teams that used Tracker for years would contradict that. The ideal tool is that which minimizes the number of things happening. LiteTracker was created with exactly this framework in mind: the 20% of features that drive 80% of results, while the rest simply slows enterprise tools to a crawl.

What to use instead — and what to look for

The Truthful Comparison, Year 2026.

The shortcut when deciding is this: if you want to keep the practice that Pivotal Tracker enforced, pick something that enforces it, not something that allows it. Tools that allow you to “configure agile” tend to drift toward whatever the loudest voice on the team wanted over the year. Tools with opinions do not go very far.

The greater migration problem is the practice rather than the smaller Tracker problem for most refugees. Transitioning From Pivotal Tracker? The upload for an import takes only one minute to complete, not a change management project that takes a quarter to execute. Your actual defense should be on the practice of having a single prioritized list, points not hours and – accepted-only velocity. Find out more on why agile fits the way it does if helpful.

It's worth reading to check the original (on story writing principles) and the (on healthier approach to estimating velocity) of Pivotal Labs. It contains same opinion as this post, but with more examples.

When NOT to bother with a Tracker-style tool

The opinion of the Tracker was that the tool would enforce the practice. If the practice is suited for your team, that’s a good thing! It’s an awful thing if it isn’t.

Avoid using a Tracker tool if.

• You're under three engineers and not yet running iterations. The forcing function is overhead, not leverage, when there's no team to coordinate. A shared note doc and a calendar reminder are fine.
• Your work is support or maintenance, not product development. Pull-based kanban with a WIP limit is the right shape; iteration ceremony makes the wrong rhythm.
• You need an audit trail more than a flow tool. Regulated industries with story-level audit requirements want Jira with all the trimmings, not a tracker that refuses to grow a custom field.
• The team has decided they don't want to run agile. A tool that enforces agile is exactly the wrong purchase. Pick a tool that mirrors how the team actually wants to work.

As a tracking company, this is what we say. If you are a four-engineer team that ships just fine on a Trello board, we aren’t needed. Velocity-based forecasting is a tool, not a religion. The purpose of the tool is to make itself invisible in order to let the work be present.

Evaluating the Impact of Tool: Would the removal of tool impacts the functionality of the team/member or not? If the answer is "the same", you're not facing a problem with your tool. If you have a practice-related issue, buying something won't help.

Frequently asked

What was Pivotal Tracker used for?

Pivotal Tracker was for software teams doing XP-flavored agile & was an agile tool. Teams utilized this approach to oversee a prioritized backlog of stories, assign point estimates to those stories, monitor their velocity in terms of accepted stories, and conduct two-week iterations aided by a fixed five-state workflow. These five states include Start, Finish, Deliver, Accept, and Reject.

Is Pivotal Tracker still available?

No. Following the announcement by VMware Tanzu, Pivotal Tracker will be declared EOL on September 18, 2024, with the service shutting down on April 30, 2025. Their only remaining data is everything exported before this date.

Why did Pivotal Tracker shut down?

Broadcom acquired VMware in 2023. After the acquisition, the Tanzu portfolio went under review according to standard procedures. Given Pivotal Tracker’s value to tens of thousands of small and mid-size teams at very small revenue per account, it was determined to not fit into the new business strategy. In March 2024 the Startup and Standard plans were retired, followed by full shutdown in April 2025.

How was Pivotal Tracker different from Jira?

Pivotal Tracker mandates a unified prioritised backlog, a single owner for each story, an accepted-only velocity, a

points-not-hours estimation, and a fixed workflow. While Jira lets you do all this, it does not enforce it in any way. Tracker was an expression of opinion as a tool; Jira is a configuration toolkit.

What is a story in Pivotal Tracker?

A story is an individual, isolated value, from the vantage point of the user. A story is written in the format of a brief narrative e.g. “a user can sign in”, “a user can recover their password”. We estimate stories with points (say 1, 2, 3, 5, 8), assign them to one owner, and move through the five workflow states, ending in Accept.

How did Pivotal Tracker velocity work?

The rolling average of points from accepted stories over recent iterations. The feature activated itself automatically whenever the product manager clicked the Accept button on a story, but not when merely finished, delivered or in-play. This means monthly velocity would measure what teams shipped not what teams committed adding bugs or chores wouldn’t inflate it.

What's the best Pivotal Tracker replacement?

The closest strategic descendants implement the same practices: single-prioritised backlog, accepted-stories velocity, and fixed iteration cadence. LiteTracker is the most straightforward choice. Shortcut and Linear have more flexibility. Jira may be adjusted to implement a Tracker-like workflow, but will not restrict it.

Can I import Pivotal Tracker data into another tool?

Certainly, if you exported your data prior to April 30, 2025. Most Tracker-shaped successors have built CSV importers just for Pivotal Tracker exports, and field mappings are almost 1:1 for stories, points, states and labels. Tools that are outside the Tracker family will accept the data, but they will not honour the iteration cadence and accepted-only velocity model.

Was Pivotal Tracker free?

In earlier years, there was a free tier, followed by a Startup tier ($), Standard tier ($$), and Enterprise tier. The Startup and Standard plans were shut down in March 2024. After that, only Enterprise was available until complete shutdown in April 2025.

Still stuck

If you were a Pivotal Tracker private beta user and now you’re the proud owner of a CSV export: the practice is the thing to preserve, not the data. This data consists of a series of narratives. The practice is what allowed the stories to be useful.

If you would like a tool that enforces the same opinions as Tracker did (one prioritised list, only accepted velocity, points not hours, no Gantt chart) then that is what LiteTracker is for. You get unlimited users on the free tier, without a per seat trap that takes a minute to import. If you're not already moving in iterations or if your team of three engineers is making do with a Trello board, save your money. Don't pay us. We prefer you signing up during the time of friction.

Whichever option you choose, ensure the practice is utilized for data migration. When CSV is not used with the discipline of a project, it is noise in a different schema.