How is Vantage different from ChatGPT or Claude?

ChatGPT and Claude are great for one-off generation. Vantage is a full workspace. It connects your tools, tracks dependencies across projects, catches conflicts between products, and surfaces what needs your attention every morning. It also remembers every past decision, so a new PM can query across all projects and get cited answers in seconds.

Do I have to switch away from Notion or Linear?

No. You keep all your tools. Vantage connects to them and builds intelligence on top. When you're ready, you can push tickets to Linear or Jira. But the value starts before you create anything — just by connecting your tools and seeing what the intelligence layer surfaces.

What happens on day one?

You connect your tools — GitHub, Linear, Slack — 2 minutes each. Vantage indexes your existing data overnight. By the next morning, you see your first decision queue: what's stale, what conflicts, what changed. No manual setup. No templates to fill out.

What if I only manage one project?

Vantage works for single projects, but it shines when you manage 3–5 or more. Conflict detection, cross-project memory, and the decision queue are most valuable when you have multiple projects that need to stay in sync. If you manage one project, start with the free tier and see if the cited query engine alone saves you time.

All data encrypted in transit and at rest. We never train on your data — the AI providers we use are contractually barred from it. You can disconnect any integration or delete your account at any time. Pursuing SOC 2 Type II.

How does Vantage keep documents and tickets up to date?

When context shifts, you add the new information and Vantage rebuilds every connected deliverable. Documents, prototypes, and tickets all update. You review the changes, accept or reject each one, and approve. Nothing updates silently, and every change is traceable.

How do I get started?

Sign up free at app.vantageos.tech. Connect your tools, and generate your first grounded document within minutes. No credit card required. Upgrade when you need more projects or features.

What is a good sprint velocity?

There is no universal 'good' velocity — it depends entirely on your team size, estimation scale, and sprint duration. A healthy velocity is one that is consistent and predictable across sprints, with committed and completed points within 10-15% of each other. Focus on stability, not size.

How many sprints do you need to calculate velocity in Jira?

You need at least three sprints of consistent estimation and sprint management to establish a useful velocity baseline. After six sprints, your average becomes reliable enough for medium-term planning. During the first three sprints, focus on estimation consistency rather than hitting a target number.

Should you count bugs and support tickets in sprint velocity?

Yes, if they consume sprint capacity they should be estimated and counted. Alternatively, some teams reserve a fixed percentage of each sprint for unplanned work (e.g., 20%) and only count planned work in velocity. Either approach works as long as it is consistent across sprints.

How-To2026-09-0310 min read

How to Set Up Sprint Velocity Tracking in Jira

Sprint velocity is the most misused metric in agile — teams either ignore it entirely or optimize for it as if shipping more story points equals shipping more value. Used correctly, velocity is a planning input, not a performance metric. It tells you how much work your team can realistically commit to in the next sprint, based on what they actually completed in recent ones.

Jira's built-in velocity chart provides this data out of the box, but only if your sprints and estimation practices are configured properly. This guide walks through the full setup: estimation methodology, sprint configuration, the velocity chart itself, and how to interpret the data without falling into the common traps that make velocity meaningless.

Step-by-step guide

Choose and configure your estimation unit

Decide whether your team estimates in story points or time (hours). Story points are recommended because they separate effort from duration and are less prone to anchoring on calendar time. In Jira, go to Board Settings > Estimation and select 'Story Points' as the estimation statistic. This tells Jira which field to sum for velocity calculations.

Navigate to your Scrum board > Board Settings > Estimation
Select 'Story Points' as the estimation statistic
Set the 'Story Points' field as a required field on your issue types to prevent unestimated work from slipping in

Establish a consistent estimation scale

Use a modified Fibonacci sequence (1, 2, 3, 5, 8, 13) and define what each number means for your team. Write these definitions down: 1 = trivial change, 2 = straightforward with no unknowns, 3 = moderate with some unknowns, 5 = significant requiring design, 8 = large with dependencies, 13 = should be broken down. Anything above 13 is too big for a sprint.

Create a confluence page or Jira project description with your scale definitions
Include concrete examples from past work for each point value
Run calibration sessions for the first 2-3 sprints until the team converges on shared understanding

Configure sprint settings and duration

Go to Board Settings > Sprints and ensure your sprint duration is consistent — velocity is meaningless if you alternate between one-week and three-week sprints. Two weeks is the most common cadence. Enable 'Parallel Sprints' only if you have a specific reason; it complicates velocity tracking significantly.

Set a standard sprint duration (most teams use 2 weeks)
Disable parallel sprints unless your workflow requires them
Configure the default start day (typically Monday) for consistency

Run three sprints to establish a baseline

Velocity data becomes useful after three to four sprints of consistent estimation and sprint management. During this baseline period, resist the urge to adjust estimates to match a target velocity. The goal is to discover your team's natural throughput, not to perform for a number. Close sprints on time even if work is incomplete — move unfinished items to the next sprint.

Commit to closing sprints on the scheduled date regardless of completion status
Move incomplete issues to the next sprint rather than extending the current one
Track the committed vs completed points for each sprint

Access and configure the velocity chart

Navigate to your board, click 'Reports' in the sidebar, and select 'Velocity Chart'. Jira displays a bar chart showing committed points (gray) vs completed points (green) for each sprint. The gap between committed and completed is your planning accuracy. If completed consistently falls below committed, you are overcommitting.

Go to Board > Reports > Velocity Chart
Set the sprint range to show the last 6-8 sprints for a useful trend view
Note the average completed velocity — this is your planning input for next sprint

Use velocity to plan the next sprint

During sprint planning, use the average of your last three sprints' completed velocity as the target for the next sprint. If your last three sprints completed 24, 28, and 26 points, plan for roughly 26 points of work. Leave a 10-15% buffer for unexpected bugs, support escalations, and estimation errors. Pull work in during the sprint if you finish early.

Calculate the average of the last 3 completed sprint velocities
Subtract 10-15% for a realistic commitment
Use the sprint backlog to fill to that capacity during planning, not above it

Common mistakes

Using velocity as a performance metric for individuals

Velocity measures team throughput, not individual productivity. The moment you tie velocity to performance reviews, developers inflate estimates to hit targets. Velocity should only be used for planning how much work to pull into the next sprint, never for evaluating people.

Comparing velocity across different teams

Team A's 30-point sprint is not comparable to Team B's 20-point sprint. Story points are calibrated within a team based on their shared understanding of complexity. Comparing across teams incentivizes point inflation and produces meaningless data.

Extending sprints to 'finish everything'

If a sprint ends with incomplete work, close it on schedule and move unfinished items to the next sprint. Extending sprints corrupts your velocity data because the chart assumes consistent sprint durations. The incomplete items carry their learning into the next sprint's estimate.

Not estimating all work that enters the sprint

Unestimated bugs, support tickets, and production incidents that consume sprint capacity but carry zero points make your velocity look lower than reality. Either estimate everything that enters the sprint or track a separate 'unplanned work' metric alongside velocity.

Tips

Add a 'Sprint Goal' text field to each sprint — it forces the team to articulate what success looks like beyond just completing a pile of tickets.

Review the committed-vs-completed gap trend line: a widening gap means your planning is getting worse, not that the team is slowing down.

Use the velocity chart in stakeholder meetings to set realistic expectations for upcoming milestones — 'at our current velocity, this epic will take three more sprints.'

Pair velocity with a cycle time report to distinguish between planning accuracy (velocity) and execution speed (cycle time).

How Vantage helps

When Vantage generates tickets from your PRD, it assigns effort estimates calibrated to your team's historical velocity data from Jira. This means generated sprint plans respect your team's actual capacity rather than assuming an ideal throughput that never matches reality.