Project Management for Engineering and Cross-Team Work, Without a Second Tool
Every team can be busy and the project can still be late. Engineering ships tickets, design waits on a decision, operations waits on engineering, and nobody can answer the one question the founder keeps asking: is this going to land on time? That question lives above any single board, and it's what Alignr projects are for.
The gap between a sprint and a project
A sprint answers "what is this team doing for the next two weeks?" A board answers "what state is each piece of work in?" Neither answers "how far along is the customer portal launch?" when that launch needs backend work, a design system update, a data migration and a support runbook, owned by four different teams.
Most teams fill the gap with a spreadsheet or a second tool, and then spend Friday copying statuses from the boards into it. The numbers are stale by Monday, and everyone quietly stops trusting them.
One hierarchy, built on the tickets you already have
A project in Alignr sits on top of your existing work in four levels:
- Project — the outcome, with a start and due date. "Launch the customer portal."
- Pillar — a major strand of the project. You can rename this level to whatever your team says: workstream, phase, epic.
- Main task — a deliverable with one owning team, an optional owner, dates, and any number of supporting teams.
- Tickets — the real work, on the real boards, with their subtasks.
The important part is the last one. Tickets aren't copied into the project. You link existing tickets to a main task, and they stay on their team's board, in their team's sprint, moving through that team's own statuses. Unlink or delete a main task and the tickets are simply left where they were.
Progress that is calculated, not typed in
Nobody updates a percentage by hand. Progress rolls up from the tickets: a done ticket counts as complete, an unfinished one counts by its finished subtasks, and a main task is the average of its tickets. Pillars and the project average everything beneath them, so a main task with ten tickets carries ten times the weight of one with a single ticket, which matches how the effort is actually spread.
A main task with no tickets yet can be set by hand to not started, ongoing or done, so early planning still shows up on the chart. And because the number is derived, it can't drift from what the boards say.
If the project view disagrees with the board, the project view is wrong. So we made it impossible for them to disagree.
For engineering teams: connect delivery to the plan
Engineers keep working the way they do now: boards, sprints, a status per ticket. What changes is that a ticket knows what it is part of. A migration ticket is linked to "Move accounts to the new schema", which sits under a pillar called "Platform" in the portal project. Closing it moves the project forward without anyone writing an update.
Dependencies show up too. A ticket that is waiting on an unfinished one is marked blocked, and the blocker is visible with its team and assignee, so "we're waiting on the API" becomes a name and a ticket instead of a sentence in a stand-up.
For interrelated teams: ownership with support
Cross-team work usually fails at the handoffs, because no one is sure who owns what. Each main task has exactly one owning team, and can list the teams that support it. The Teams view then shows, for each team, what they own, what they're supporting, and how the tickets on their boards are doing. For each person it shows open, done and overdue counts.
That makes two conversations easier. A lead can see that their team is supporting five main tasks and owning two, which explains why the owned ones are slipping. And a project manager can see which team is carrying the overdue work before the deadline, not after.
Five ways to look at the same project
- Overview — overall progress and health: done, on track, at risk or overdue.
- Tree — the full project, pillar by pillar, down to individual tickets.
- Timeline — the plan against dates, so overlaps and gaps are easy to spot.
- Insights — a burn chart and the trends behind the numbers.
- Teams — who is carrying what.
Health is a comparison, not a mood. Something is "at risk" when its progress trails the time elapsed by a meaningful margin, and "overdue" once it is past its due date and unfinished. It's a prompt to look, not a verdict.
How to set one up in an afternoon
- Start with the outcome. One project, one sentence, one due date.
- Add three to five pillars. If you need more, the project is probably two projects.
- Write main tasks as deliverables, each with one owning team. If you can't pick one owner, that is the first problem to solve.
- Link the tickets that already exist. Resist creating new ones just for the project view.
- Check the Teams tab once a week in your planning meeting, instead of collecting updates.
Who this is for
If your whole company is a single team on a single board, you don't need this; a sprint board is enough, and a light mix of kanban and Scrum will carry you a long way. Projects start earning their place when work crosses teams: a product launch, a client implementation, a migration, a compliance deadline. The same goes for engineering groups that split into platform, product and operations.
If that sounds like you, create a project from the Projects page in your workspace, link a few tickets, and see what the roll-up says. New to sprints first? Start with planning your first sprint in one afternoon.