Plan a sprint against the team you actually have.
Capacity is calculated from approved leave, standups and retros are matched from the calendar, and every merged pull request is linked to the issue it closed. Nobody has to ask who is away, and there are no lists to reconcile at the end of the sprint.
Full access, no card required.
Three days of approved annual leave came out of the sprint on their own. The leave ledger belongs to People and the sprint belongs to Projects, and one reads the other because they are one database.
What it solves
Four problems a standalone tracker cannot fix.
Each of these needs something a standalone tracker cannot see: who is on leave, what is on the calendar, who is on the payroll, and what actually broke last week. Projects HQ sees all four.
Sprint capacity is calculated from approved leave, so a fortnight with two people away is planned that way from the start. Nobody has to ask who is off; the approval in Human Resources already did the work.
Standups and retros are matched from the calendar instead of typed up by hand, so the notes always describe a meeting that really happened. If a retro never met, the page says so plainly instead of showing an empty form.
Every pull request is linked to the issue it closes, and every contributor is a real employee, so the code and the board always tell the same story. There is nothing to reconcile at the end of a sprint.
When a hotfix closes, it writes its own retro line, with the severity and the area filled in from the issue. What a team would have forgotten by Friday is written down the same day.
The sprint plan
The plan already knows who is away.
Capacity already has approved leave taken out. Next to it you can see velocity from recent sprints and any points added after the sprint started. None of those numbers is typed in by hand, so the plan stays honest.
The ceremonies
Plan, standups, retro and epics.
Every sprint has four tabs. Plan takes approved leave into account, Standups and Retro match themselves to the calendar, and Epics follows work that runs across several sprints.
Inside the sprint
- Plan. Capacity with approved leave already deducted, velocity from past sprints, and points added after the start.
- Standups. Matched from the calendar instead of logged by hand.
- Retro. Learnings and action items, with action items appearing once the retro records measured outcomes.
- Epics. One progress figure for work that runs across several sprints.
Connected to the rest of NearSync
- Human Resources. Approved leave sets sprint capacity, and work is assigned to real employees, not separate login accounts.
- Comms. Standups and retros match themselves to calendar meetings, so the notes and the meeting never drift apart.
- Operations. Boards come from the template library, and a workflow can be triggered when a sprint or an issue changes.
- Custom fields. Add your own fields to issues, without waiting on us to build them.
None of this needs an integration or any setup. Leave, the calendar and the sprint all happen in NearSync, so they agree with each other by themselves.
The board
Kanban or list, with limits it holds you to.
A WIP limit that is only a convention gets ignored by the second week. Here the board enforces it, and an issue carries its type, points and priority wherever it is shown.
Roadmap
Quarters and weeks, on the same roadmap.
Milestones and spans that zoom from a quarter down to a week, built from the same issues the board is working, so the roadmap cannot quietly disagree with the sprint.
Scrum Manager
An AI that works the sprint, not one that reports on it.
It runs the ceremonies, watches what is slipping, and tells you what needs a decision before the standup rather than after it.
Scrum Manager, your working scrum master. It briefs, recommends, and runs the ceremonies.
Sprint 18 ends tomorrow. 25 of 29 points are done and the sprint goal is within reach.
Two issues will not close in time and one bug still has no owner. I have put both on your list below. I will keep watch and flag anything else that needs your call.
Backlog
What is not planned yet, and what should be next.
The backlog is where the roadmap gets its material. Groom it here and the next sprint plans itself from real capacity rather than optimism.
Drag issues into sprints to plan your next iteration
Every capability
Everything in Projects HQ, in eight areas.
Each page covers what you can do, how to set it up, who can use it, and where it stops. There is also Reports and Analytics, with its own boards, reports and insights; it does not have a page yet.
Planning
The guides, in full
Guides written for the people running the sprint day to day.
Start here
The unit of work, and the board it lives on.
Planning
Deciding what goes in, and drawing what was promised.
Running it
The fortnight itself, and what the numbers say afterwards.
Setting it up
Changes here reshape the board for everybody on it.
The AI
The one that works the sprint with the team.
The questions we get asked.
Anything longer lives in the help centre.
How many projects and sprints can we run?
As many as you have teams. Boards, backlogs and roadmaps are unlimited, with WIP limits if you want the board to hold you to something.
Does sprint capacity know who is away?
Yes. Approved leave comes out of capacity before you plan, because the leave request and the sprint are in the same database.
Does it connect to GitHub?
Yes. Commits and pull requests show up against the issue they belong to, so the board reflects the work without anybody moving a card.
Is the AI Scrum Master included?
Yes, in every plan. It runs the ceremonies, watches the sprint and tells you what needs a decision before the standup.
Your sprints, backlog and roadmap in one place.
Set up your own sprint in half an hour, with pull requests linked to the issues they close.