Project team

“How is the team doing?” gets answered by looking at one screen, not by building a report. The Team tab of every project reads what has already happened on the tasks (who closed them, when they went to review, which ones were reopened) and lays it out by day and by person, with a date filter.

For a team that ships software, it does three things:

• Shows the real pace: how many tasks close each day and how many are waiting for review. A pile of tasks sitting in review is a bottleneck you can see in seconds, not at the end of the sprint.
• Prepares the meeting in a minute: on Monday, pick “last week” and the screen already says what got done and who did it. There is nothing to collect.
• Shows progress without explaining it: the link with the chosen period can be shared as it is.

Open it from the Team tab of the project, or press 8 inside the project.

What you see

Workspace members see it. A project guest doesn’t: it’s data about people on the team.

Numbers for the period

A band with the project’s tasks and how many are done, in review, in progress and not started, with their percentage and a progress bar. It’s the state as of the last day of the chosen period. Canceled tasks aren’t counted.

Progress to date and forecast

A chart with the done tasks to date, day by day, the ones in review stacked on top and the scope (how many tasks the project had that day). If there’s a pace, a dashed line extends it to the estimated end.

Above it you see the calculation: tasks per working day, how many of the last 10 weekdays had work, how many are left, how many weekdays remain at that pace and the end date.

• Pace = (closed − reopened) ÷ days with activity (closing, sending to review or reopening) in the last 10 weekdays.
• Estimated end = what’s left ÷ pace, counted Monday to Friday. It doesn’t know about holidays.
• It’s a linear extrapolation: if the pace changes, so does the date. If nobody closed anything in the last 10 weekdays, there’s no date.

By day

One row per day in the period, with who worked, how many tasks they closed, how many they sent to review, how many were in review at the end of the day, how many they reopened and the running total of done.

• Days with no activity (a weekend, a holiday) don’t disappear: they show as “No activity”, so it’s clear nobody worked, not that data is missing.
• If an already closed task is reopened and closed again, it counts as a closing each time. The row flags those as “closed again” and the running total subtracts reopenings, so the numbers always add up.
• Days are counted in your time zone. A closing at 12:30 am lands on the day you see on your clock.

By person

A summary of each person for the period: tasks closed, sent to review, reopened, working days with activity and, if you use time tracking, the time logged. Expand a person to see their tasks day by day, with the identifier and a link to each one.

Progress by group

A table with the tasks, the done ones and the ones in review for each group, with a progress bar. Group by milestone, label or parent issue with the selector in that section.

• Who: the people behind the group (assigned to its tasks or who closed them), the most involved first.
• Hours: the time logged in the period to the group’s tasks, if you use time tracking. Canceled tasks aren’t counted.
• When grouping by parent issue, the parent task’s status (not started, in progress, in review or done): each parent is a block or deliverable.

Click a header to sort by that column.

Filters

• Period: shortcuts for today, this week, last week, the last 7 and 30 days and the current cycle, or any date range (up to 366 days).
• People: one or several. It filters the activity (the “who”); the project’s state numbers don’t change.
• Milestone, label and cycle: narrow down the tasks that are counted.

Everything recalculates when you change a filter. If the period has no activity, the screen says so instead of showing zeros. The period and the filters live in the page address: copy the link and whoever opens it sees the same thing.

How it’s counted

• Done: a task in a completed status. In review: a task in a started status that has Unblocks the tasks it blocks turned on (the factory In Review). It’s decided by the status type and option, not by its name, so a status you rename keeps counting. See Workflow states.
• Who and when: comes from each task’s status change history. A change made by an agent through MCP counts as the person who owns its key.
• Tasks without history: the oldest ones may not have any. If they’re done, their completed date is used and they’re attributed to the assignee; the screen tells you how many.

At the bottom of the screen you always see when the data was read and which time zone the days were counted in.