Story points or hours, and parallel sprints when squads share a project

Two things people assume a calm, opinionated tracker cannot do: estimate in story points, and run more than one sprint at a time. Utter used to prove them right on both counts, on purpose. It does not anymore. Both are here, both are opt-in, and neither one turns the tool into an everything-suite. Here is how they work and, just as important, where the defaults still point.

Estimate in points or hours, your call

Estimation is a per-project setting now. Open a project's settings and pick how it estimates work: time, story points, or none. Time is still the default, so nothing changes for the teams that never wanted points. Flip a project to points and its estimation surface changes to match.

That per-project choice matters more than it looks. A design team can run on time while the platform squad runs on points, in the same workspace, without either one bending to the other. The switch is not global and it is not permanent; change it whenever the team's practice changes.

The Fibonacci pick, right on the issue

When a project uses points, the estimate on an issue becomes a Fibonacci quick-pick: 1, 2, 3, 5, 8, 13, 21, and a "?" for "not estimated yet." One click sets it. There is a custom field next to the scale for the rare estimate that does not fit the ladder, but the scale is what you will reach for.

Points ride along everywhere the issue goes. On the board, each card wears its points, so you can read the weight of a column at a glance without opening anything.

Velocity and burndown follow the unit

This is the part that makes points real rather than decorative. A points project reports velocity and burndown in points, not issue count. A sprint reads "committed 34, burned 29" in points; the burndown line falls by the weight of each card as it closes, not by one per issue. A time project keeps its issue-count velocity, exactly as before, so the switch never changes the numbers for teams that did not ask for it. The unit is chosen once, per project, and every report downstream respects it.

Flow metrics are the same either way. Cycle time and lead time with percentiles are computed from each issue's own history, so they do not care whether you estimated in points, hours, or nothing at all.

Parallel sprints when squads share a project

The other old limit was one active sprint per project. Starting a sprint used to quietly pause any other running one. That is gone. A project can now run several active sprints at once, so two squads sharing a codebase each keep their own sprint running side by side.

Start a sprint and it goes active without touching the others. The board's sprint switcher scopes the columns to whichever sprint you are looking at and marks every active one, so "which board am I on" stays a one-click answer even with two or three running. Burndown gets a small sprint picker for the same reason: pick the squad, read its line.

Still time-first by default

Being honest about the defaults is the whole point of a calm tracker. Time estimation is still the default, and a fresh project runs one sprint at a time until you decide otherwise. Nothing here forces planning poker on a team that never wanted it, and nothing forces two squads onto one project when one sprint is plenty. These are options you turn on when the shape of your team calls for them, not ceremony bolted onto every project.

If your team never trusted point inflation, keep the default and let issue-count velocity be blunt in a good way. If you run on poker, turn the project to points and estimate in the scale you already know. Both are first-class; neither is the tax.

In the API too

Everything above has a programmatic twin. A project's estimation unit and an issue's story points are both in the REST v1 API, and because the MCP server derives from the same spec, an agent can set them in natural language. Turning a project to points and pointing an issue is two calls:

curl -X PATCH https://utter.ae/api/v1/workspaces/acme/projects/APP \
  -H "Authorization: Bearer $UTTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"estimation_unit":"points"}'

curl -X PATCH https://utter.ae/api/v1/workspaces/acme/projects/APP/issues/APP-1 \
  -H "Authorization: Bearer $UTTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"story_points":8}'

const base = "https://utter.ae/api/v1/workspaces/acme/projects/APP";
const headers = {
  Authorization: `Bearer ${process.env.UTTER_API_KEY}`,
  "Content-Type": "application/json",
};
await fetch(base, { method: "PATCH", headers, body: JSON.stringify({ estimation_unit: "points" }) });
await fetch(`${base}/issues/APP-1`, { method: "PATCH", headers, body: JSON.stringify({ story_points: 8 }) });

import os, requests

base = "https://utter.ae/api/v1/workspaces/acme/projects/APP"
h = {"Authorization": f"Bearer {os.environ['UTTER_API_KEY']}"}
requests.patch(base, headers=h, json={"estimation_unit": "points"})
requests.patch(f"{base}/issues/APP-1", headers=h, json={"story_points": 8})

Try it on a real project

Open a free workspace, set one project to points and estimate a sprint in the Fibonacci scale, or start a second sprint on a project two squads already share. Both are on every plan, and both are the kind of thing you only miss until it is there.