One Team, Three Projects, Three Sprints
A sprint here belongs to a project, and a task can only join a sprint that belongs to the same project. For a squad that serves one engagement that is invisible. For a standing team carrying four client projects at once, it is four sprints, four burndowns and four velocities for one two-week cadence.
There are two ways a delivery team can be organised and the software you use quietly assumes one of them. Either the team is built around the work — a squad per product, per client, per engagement — or the work is brought to a standing team that carries several things at once. Both are ordinary. Only the first one fits the way sprints are modelled here, and it is worth knowing which of the two you are before you commit a planning ritual to it.
The mechanical fact is one line long. A sprint belongs to a project. When you put a task into a sprint, the sprint you are allowed to choose must belong to that task's own project — that is checked, not merely expected. Everything else in this article is a consequence.
What follows from one line
| The thing | What it is scoped to | What that means for a shared team |
|---|---|---|
| The sprint | One project | One cadence across four engagements is four sprint records, opened and closed in step by hand |
| The backlog | One project | There is a backlog per engagement, and no single queue the team pulls from |
| Committed and done points | The tasks in that sprint | A round's commitment is four numbers rather than one |
| Velocity | One project | Four averages, each built from that project's sprints alone |
| Carry-over at close | That project's backlog | Unfinished work returns to the engagement it came from, which is correct and is also four separate tidy-ups |
None of this is broken. A sprint scoped to a project is a coherent design and it is the one most tools started from, because the original idea of a sprint came out of product teams where the project and the team were the same object. The question is only whether that assumption matches your building.
The model is not wrong about sprints. It is making an assumption about teams, and the assumption is that a team is a project. Whether that is true is a fact about your organisation, not about the software.
The team shape this is about
It is worth being concrete about who this actually affects, because it is a minority of teams and a very consistent one: an engineering or delivery group of six to fifteen people, employed by one firm, working a portfolio of client engagements simultaneously. Some engagements are a few days a month; one or two are most of the capacity. People move between them within a single week. The team is the stable thing and the projects come and go around it.
That is the standing arrangement across a great deal of engineering services, systems integration and agency work — and it is the shape that a project-scoped sprint fits worst, because the one number the team actually wants is capacity across everything, and that number is the one that has been divided.
Three ways to live with it, in order of how much you will like them
-
Run the sprints in parallel and accept the bookkeeping
Open four sprints on the same dates with the same name, and close them together. The board per project is genuinely useful — a client-facing engagement lead sees only their own work, which is often what you want anyway. What you give up is the single commitment number, and you rebuild it by adding four figures on a Monday morning. It takes minutes and it is the option most teams land on.
-
Use one project as the team's own container
Where the engagements are small and internal rather than client-billed, a single project representing the team, with labels or custom board columns marking which stream each task belongs to, gives you one backlog, one burndown and one velocity. The cost is that per-engagement cost and budget then live at the label level, which the costing side is not built to report on. Good for internal platform teams; poor wherever a client has to see their own project.
-
Keep sprints for the one engagement that deserves them
The least fashionable answer and often the right one. Iteration is a tool for uncertain work with a stable team; most of a mixed portfolio is neither. Run the cadence on the engagement where scope is genuinely unknown, and plan the rest with dependencies, milestones and dates, which is a different machinery in the same product and carries no per-project ritual at all.
One detail that decides how expensive option one is
Sprints are not carried by a project template. A template copies tasks and their hierarchy, dependencies, milestones, checklists, labels and custom board columns — and clears sprint allocation deliberately, so a new job never inherits last quarter's round. That is the right behaviour for the thing a template is for, and it does mean the parallel-sprint arrangement is set up by hand each time rather than stamped out. If you are choosing between the three options above, weigh it: what a clone carries is worth reading before you decide how many projects you want to keep in step.
The arithmetic problem underneath the bookkeeping
There is a second-order point that survives even if we built cross-project sprints tomorrow, and it is the reason this is not simply a feature request. Story points are not a unit. They are an estimate calibrated inside one team on one body of work, and the same team estimating a familiar client's work and an unfamiliar one's is not using the same scale.
So four velocities that sum to forty is a fact about four estimation habits and not about forty of anything. A single blended figure would be easier to read and no more true. If you want capacity across a portfolio, hours are the honest unit and they are logged against tasks regardless of any sprint — which is a quieter answer than a chart, and it is the one that holds up in a conversation with a client.
The short version
If your team is a project, sprints here work exactly as you would expect and this article is about somebody else. If your team carries a portfolio, decide deliberately: run parallel sprints and accept adding four numbers on a Monday, collapse to one container project and give up per-engagement costing, or keep the cadence for the single engagement whose scope is genuinely uncertain and plan the rest with dates and dependencies. What you should not do is start the ritual across four projects without having chosen — that is the version where three months later somebody quietly stops closing the sprints and nobody notices, because four burndowns going stale looks the same as four burndowns nobody reads.
What AWRA OpsHub does today
- Sprints with a goal, dates and a status, opened, run and closed per project, with unfinished work returned to that project's backlog at close.
- Story points, burndown and velocity computed from the tasks in the sprint, resolving your own board columns rather than a built-in status name.
- A per-project backlog of everything not yet committed to a round.
- Custom board columns per project, carried by a template so a way of working is captured once.
- Hours logged against tasks independently of any sprint, which is what makes the capacity answer available even where the point totals are not comparable.
More we can add to your workspace
- A sprint that spans several projects, so one cadence across a portfolio is one record to open and one to close.
- A team backlog drawn from more than one project, giving a shared squad a single queue to pull the next piece of work from.
- A capacity view across every engagement a person is working on, expressed in hours rather than in points from four different scales.
- Sprint cadence carried by a project template, so a new engagement joins an existing rhythm at the moment it is created.
Where we point you to a specialist
- We will not blend velocities from separate projects into one figure. Points are calibrated inside one body of work, so the sum would read as a measurement while being an artefact of four estimation habits — and a number like that gets used in a client conversation eventually.
- We will not tell you whether your team should run sprints. That is a judgement about how uncertain your work is and how stable your team is, and both are things you can read from inside your own team better than any vendor can from outside it.
The first two lines are the same change seen from two ends — a shared cadence needs a shared queue to be worth having, and either one alone leaves the team adding numbers by hand on a Monday.
What we can build for Japan on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Japan, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If rounding at the currency's own precision, consumption tax subtotalled per rate, a registration number field, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The arithmetic before the document
Japan is the market where our own arithmetic is the first thing to fix rather than a field we are missing. The invoice, quotation and point-of-sale paths round money to two decimal places as a hardcoded literal, and the yen has no minor unit — so a three-line invoice at the standard rate produces a consumption tax of ¥423.4, an amount that cannot be invoiced or paid. We already hold the correct number of places for every currency as reference data; that code simply does not read it. On top of that sits the requirement that gives the fix its shape: a qualified invoice must show consumption tax categorized by tax rate, and the rounding is permitted once per rate rather than once per document. Our invoice carries a single tax figure with the rate on the line, so the per-rate subtotal in between does not exist — and it is the same piece of work as the rounding, which is why we would build them together rather than in sequence. Separately and smaller: a tax registration number on the organization, on customers and on suppliers, since no column for one exists anywhere today.
Banks, payments and a currency with no decimals
Bank statement feeds and local payment rails wired into the Payments Register, with documents raised and reported in yen at the precision the yen actually has. What we will not do is treat our copy of the public register of qualified invoice issuers as authoritative for your credit entitlement — we will hold the number you recorded and the date you checked it, and leave the checking where it belongs.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Japanese payroll engine with income tax withholding, the standard-remuneration social insurance grades and the year-end adjustment, computed on live employee records rather than rebuilt in a spreadsheet each December.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions before you commit a team to a cadence
Can one sprint hold work from two different projects?
What you will hear
A quick yes, or a slower "you would use a shared project".
How to read it
The slower answer is the honest one and it is ours. Ask what the workaround costs at the reporting end, because a shared container usually means per-client cost and budget stop being reportable — which is a bigger loss than the chart you gained.
Where does unfinished work go when a sprint closes?
What you will hear
A backlog.
How to read it
Ask whose backlog. Returning to the originating project is correct and is what ours does; silently carrying into the next sprint is the behaviour that inflates the following round and makes a struggling commitment look healthy.
What is the team's capacity next fortnight, across everything?
What you will hear
A points figure, produced confidently.
How to read it
Ask which projects it covers and whether the points came from the same estimating sessions. If it is a sum across engagements, it is four scales added together. Hours are the boring answer and the one you can defend.
Show me a sprint from six months ago.
What you will hear
Either a clean record or a search.
How to read it
The search is the finding. A ritual that stopped being maintained leaves exactly this trace, and it is the most common outcome of starting sprints across a portfolio without deciding who closes them.
See sprints, and the planning that is not sprints
Sprints, story points, burndown and velocity per project — alongside dependencies, milestones, budgets and costing for the engagements that plan better with dates.
Explore project deliveryFrequently asked questions
Can one sprint cover work from more than one project?
A sprint belongs to a project, and when you add a task to a sprint the choices offered are the sprints belonging to that task's own project — it is enforced rather than merely conventional. A team running one cadence across four engagements therefore runs four sprint records opened and closed in step. The board per project is genuinely useful for client-facing work; what you give up is a single commitment figure, which most teams rebuild by adding four numbers once a fortnight.
Is a shared container project a reasonable workaround?
For internal work, often yes: one project representing the team, with labels or custom board columns marking each stream, gives you one backlog, one burndown and one velocity. It falls down wherever money matters, because budget, cost rate and bill rate live on the project — so per-engagement costing disappears into a label the costing reports are not built to split on. Use it for platform and internal teams, not for a client portfolio.
Do sprints come across when I create a project from a template?
No, and deliberately. A template carries tasks and their hierarchy, dependencies, milestones, checklists, labels and custom board columns, while clearing dates, assignees, progress and sprint allocation — so a new job never starts inside last quarter's round. The consequence for a portfolio team is that parallel sprints are set up by hand each time rather than stamped out, which is worth weighing before you decide how many projects to keep in step.
Why not just add the four velocities together?
Because points are calibrated inside one team on one body of work, and the same team estimating a familiar client's work and an unfamiliar one's is not using the same scale. A sum would be easier to read and no more true, and a figure like that gets quoted in a client conversation eventually. If you want portfolio capacity, hours are the honest unit — they are logged against tasks whether or not a sprint exists, so the answer is already available.
What happens to work that does not finish in a sprint?
Closing a sprint returns every unfinished, uncancelled task to the backlog of the project it belongs to, with its sprint allocation cleared. Carry-over is then a deliberate act — you put the task into the next round yourself. That is more work than automatic rollover and it is better, because it forces a decision about whether the work is still worth doing rather than letting a commitment quietly grow.
