Estimates, time and teams

A board made of titles answers what. This page is the three questions it cannot answer: how big is this, how long did it take, and whose work is it.

All three are optional and none of them is on to begin with. A server that ignores every one of them has exactly the tracker it had before — that is the point of leaving them off. Turn on the ones that answer a question somebody is actually asking, and leave the rest alone.

Estimates

An estimate says how big a piece of work is. Not how long it will take: how big. "Rewrite the pricing page" is a bigger thing than "fix the typo in the footer", and everybody on the team knows that before anybody knows what day either of them will happen on.

That is the whole reason estimates are points rather than hours. A point is a size relative to the other issues on the board, so a team can agree that something is a 5 without committing anybody to an afternoon. Hours are the next section; the two are deliberately separate.

What points buy you, once a few issues carry them:

• A column header that sums them, so In Progress reads 12 points and you can see what it would cost to empty it.
• A cycle burn-up drawn in points instead of issues, which is a far better picture of a fortnight when three of its issues are enormous and eleven are trivial. See cycles.
• A filter: everything unstarted and bigger than a 3.

Choosing a scale

Points are numbers, but teams spell them in different ladders, and a ladder that offers every number from 0 to 100 is a ladder nobody agrees on. So the project declares which rungs it offers, in its own form under projects:

No estimates is where every project starts, including the ones that existed before this page did. A ladder nobody chose has no business decorating a board, so until somebody picks a scale there is no estimate control to see and no empty row on any card.

Which of the other four is a matter of taste, and the taste is about how you argue:

• Linear is the simplest thing that works, and it is the right answer for most servers. Five sizes, and the difference between a 4 and a 5 is small enough not to be worth a meeting.
• Fibonacci is the classic. The gaps widen as the numbers grow, which is an honest way of saying that nobody can tell a 12 from a 13 — past a point the only useful answer is "bigger than the last big one".
• Exponential widens harder still. It suits work that is genuinely either tiny or enormous with nothing in between.
• T-shirt replaces the argument about numbers with an argument about letters, which some teams find much easier. XS to XL, and the sums still work underneath because each size is a number in disguise.

Switching a scale changes nothing about the issues

A scale is a display choice, so you can change your mind on a Tuesday afternoon with forty issues already estimated and nothing is rewritten, converted or lost. That is deliberate: an estimate is stored as a plain number, which is what lets the column headers and the burn-up add it up at all.

The consequence is worth knowing before it surprises you. After a switch, an issue can be carrying a value the new scale does not offer — a fibonacci 13 under a t-shirt scale, an 8 under a linear one. That is not an error. The issue shows the raw number, nothing refuses to save, and the next time somebody opens the picker they get the new ladder. Re-estimate it if the old number bothers you, or leave it: it was a real size when somebody chose it.

The triangle

An estimate draws a small triangle that fills from the bottom, and it fills by rank rather than by value: whatever sits at the top of the project's ladder draws a full triangle. A fibonacci 21, an exponential 64, a t-shirt XL and a linear 5 all read as the biggest thing this team files, even though the numbers differ by a factor of thirteen.

Mapping it by value instead would make every t-shirt estimate look trivial next to an exponential one, and the glyph would be useless the moment you looked at two projects side by side. An unestimated issue draws the dashed outline.

The two settings

Under the scale, the project's form carries two switches. Both are soft: neither one goes back and changes an issue you already have.

Allow a zero estimate decides whether 0 is one of the rungs the picker offers. It is on by default, because every scale above opens with a zero and "this is nothing, and we know it is nothing" is a real answer. Turn it off in a team that reads 0 points as nobody has estimated this yet — the picker then starts at 1, and an issue that already carries a 0 keeps it. It changes what you are offered, never what an issue may hold.

Require an estimate before an issue can be started is the useful one, and it is worth a paragraph because it is a rule about a moment rather than about an issue.

With it on, an issue cannot enter a column whose type is started while it has no estimate. Drag it there, pick the column on the issue's page or on a list row, use the command palette, the card's State button in Discord or /task state, and every one of those routes answers the same thing: this project requires an estimate before an issue can be started. Size it and the move goes through.

What it deliberately does not do is reach backwards. Ticking the box on a project with six things already in progress leaves all six exactly where they are — none of them is refused, hidden or flagged. A setting that froze a board the moment it was switched on would be a setting nobody dares try. The same goes in the other direction: nothing stops an unestimated issue being closed, cancelled, archived or moved back to the backlog. It is a gate on starting, which is the moment a team is deciding what to pick up, and that is the only moment where the question "how big is this?" is actually worth asking.

The gate does nothing at all on a project whose scale is No estimates, since there is nothing to estimate with. Turn the scale on first.

Where an estimate shows up

Time

Points say how big. Time says how long — and because those are two different questions, they are two different things on the issue, neither one derived from the other.

Keeping them apart is what makes either one worth having. An estimate that quietly turns into the actual is a number that can never be wrong, and therefore never teaches anybody anything; an actual with nothing to compare it against is a number nobody reads.

The time estimate

One property on the issue, in minutes, from 1 to 100,000 — the ceiling is roughly sixty-nine days of non-stop work, and it exists to catch a form that sent milliseconds rather than to be a rule about anything. Leave it empty on the issues where it would be a guess; nothing requires it and no gate depends on it.

The log

Logged time is a list rather than a counter. Each entry is one stretch of work and carries:

A list rather than a number, for exactly the reason the activity trail is one: a counter is a figure anybody can overwrite and nobody can explain. With one row per stretch, the total is a sum you can take apart — who did what, on which day — and one person can correct their own entry without touching anybody else's.

The issue shows the total logged against the estimate where it has one, so how long so far can be read against how long we thought without anybody doing the arithmetic. An issue may carry 100 entries; past that, the log is longer than the issue it belongs to and what you want is a second issue.

An entry is yours. You can edit or delete the ones you logged, and only those — changing somebody else's record of their own afternoon needs Moderate: Manage Server, the Manager and Admin presets, or any role or member row that carries it. Deleting an entry removes it from the total; nothing else changes.

The running timer

Instead of logging a stretch afterwards, press Start timer and let FlaviBot count. The issue shows it running and the number ticks in front of you.

Three things about the timer that are worth knowing before you use it:

• One timer, per person, per server. Not one per issue. A person works on one thing at a time, and a product that let you run four timers at once would be a product that silently bills the wrong issue every time somebody forgot one.
• Starting a second timer stops the first, and the first is logged before the second begins. You do not lose the stretch you were in the middle of, and nothing is counted twice.
• Stopping writes one entry, rounded to the nearest minute with a floor of one, dated today. The entry is then an ordinary entry: edit its note, fix its minutes, delete it.

A running timer is not part of the logged total until it stops, which is why the issue shows it separately. Nothing stops it for you — no end of day, no idle timeout — so a timer left running overnight is a long entry to correct in the morning rather than a number silently added behind your back. If you would rather not think about it at all, skip the timer and log the minutes by hand; the log does not care which way the entry arrived.

Where time shows up

Nothing about time is ever announced: no DM, no channel message, no reminder that your timer is running. A tracker that nags people about a clock is a tracker people stop starting timers in.

Teams

A team is a named list of members with an optional free-text role next to each one — your moderators, the art crew, the platform team. An issue can be put on one.

One list, both modules

The teams here are the same teams as the calendar's. Not a copy, not a second list that looks like it: one row, read by both. Make Moderation once and it is there to invite to an event, to lay out an availability grid, and to own an issue.

That means teams are created and edited in one place — the Teams tab of the Events page — and the limits there are the limits here: 25 teams per server, up to 100 members each, a name of up to 64 characters. Renaming a team renames it everywhere; deleting one removes it from everywhere.

Deleting a team does not delete the issues that were on it. They simply stop being on a team, exactly as they would if you had cleared the field by hand — disbanding a team widens its work, it does not destroy it.

A team is not a second assignee

An issue is still assigned to one person, and the team sits next to that rather than instead of it. They answer different questions:

Assigned to Ana, on the moderation team is a normal issue. On the moderation team, unassigned is the more useful one: it is work that belongs to a group and has not been picked up by anybody in it yet, which is precisely what a team wants to look at on a Monday.

Putting an issue on a team notifies nobody. Nobody on it is DMed, no role is mentioned, and the card does not ping. Following an issue still comes from being involved with it; see notifications.

Where a team shows up

Grouping by team is what most servers turn teams on for. One column per team, the No team column on the end holding everything nobody has claimed, and a board that answers what is each group carrying without anybody writing a report.

The three in Discord

Everything above is on the card and in /task view, and three subcommands set them without opening the dashboard:

estimate and team need Edit like every other change — Edit own issues by default, Edit any issue with a role or member row that carries it — except a time entry, which is always your own and needs only Log time. The full list is in who can do what, and the rest of the Discord side is in the Discord side.

When one of these refuses

Limits

Next: GitHub.