Sprints & Metrics

Sprints

A Sprint (also called an Iteration in some contexts) is a short time-boxed period — typically 2 weeks — during which a team implements and delivers work items.

Every sprint has:

• Name — Sprint identifier
• Type — Sprint or Iteration
• Sprint type — Standard or Non-standard, whether the sprint is comparable with the team's other sprints. See Sprint Type
• State — Future, Active, or Completed
• Date Range — The first and last planned days, as calendar dates. The sprint includes the whole of its last day
• Team — The owning team (optional)
• Ownership — Owned (by Wayd) or Managed (from external system like Azure DevOps)

Managed sprints may have External Metadata such as the Azure DevOps iteration path.

A sprint's state follows its dates, and Wayd works it out whenever the sprint is shown, so it is never out of date between syncs:

• Future — before the sprint starts.
• Active — from the start until the end. A sprint starts when the team starts it, or else at the beginning of its first planned day. It ends when the team completes it, or else at the end of its last planned day, so a sprint is Active for the whole of its last day unless it was completed earlier.
• Completed — after the end.

Days are counted in the team's time zone, from its operating model. A team has one Active sprint at a time: a sprint becomes Active only once the previous one has ended, and starting the next sprint ends the previous one. A sprint whose team is not mapped to a Wayd team follows its planned days in the system default time zone.

For example, take a sprint planned to start on Monday that the team starts on Tuesday morning. Once the start is recorded, the sprint is Future on Monday and Active from Tuesday morning, which is what its timeline, history and metrics use. Until someone presses Start, Wayd has only the planned dates to go on, so on the Monday itself the sprint shows as Active.

Timelines, countdowns and health follow the days a sprint is Active, not its planned dates. On the sprint page, the My Team Sprints cards on Home and the sprint cards on a PI iteration, the timeline bar, Days Remaining and the health tag run from the day the sprint became Active to its last Active day: day 1 is the day the team started it, or else its first planned day, and the last day is the day it was completed, or else its last planned day. The date range shown beside a sprint stays the planned one. A sprint whose team is not mapped to a Wayd team uses its planned dates.

Sprints are mapped to PI iterations to connect team delivery cadence to the broader planning schedule.

Starting, Completing and Reopening a Sprint

A sprint's synced dates are what was planned. Teams often start or finish on a different day — the planned Monday is a holiday, so they plan on the Friday before — so a team records when it actually started and completed the sprint in Wayd. Nothing is written back to Azure DevOps, and syncing never changes these dates.

Action	What it records	When it is allowed
Start	The moment you choose — now by default, or earlier — as the sprint's actual start	After the team's previous sprint started (and not before it was completed, if it was), up to the end of the sprint's last planned day, and before the next sprint's start. The team's first sprint can be started up to 3 days before its planned start.
Complete	The moment you choose — now by default, or earlier — as the sprint's actual end	After the sprint started — pressing Start is not required, its commitment point having passed is enough — before a later sprint has started, and once any earlier sprint the team left open has been completed
Reopen	Clears the actual end	While the team has not started a later sprint and, for a sprint the team started, while no other sprint of the team is open

The dialog offers only the moments the rules allow, so a recorded start or end never overlaps the team's other sprints. A moment can't be in the future. Activity records both the moment you chose and when you recorded it.

A team has one open sprint at a time. If the previous sprint is still open when you start the next one, Wayd asks you to confirm completing it. On confirm, the previous sprint is completed at the same moment the new one starts.

When the team doesn't record a date. If the team doesn't start or complete the sprint in Wayd, the sprint follows its planned dates: it starts at the beginning of its first planned day and ends at the end of its last, counted in the team's time zone from the operating model in effect on the sprint's planned start. The only exception is when it meets a neighbouring sprint: a sprint doesn't start until the previous one has ended, and where the planned dates overlap it ends when the next one starts (see below).

The sprint page shows the Planned start and Planned end beside the Actual start and Actual end the team recorded, which read — until they are recorded. Recorded times are shown in your time zone. Length counts the days the sprint actually runs: its planned days, moved by any recorded start or end.

Commitment point. Metrics take the team's commitment when the team starts the sprint, or, if it doesn't, at the end of the team's commitment grace period after the planned start — with the default of 1 day, the end of the first planned day. That leaves the team its first day to plan: work added on that day counts as committed, not as added scope.

Overlapping sprints in Azure DevOps. Azure DevOps lets one team's iterations overlap, and Wayd keeps the source dates as they are. Where they overlap, a sprint the team hasn't completed ends when the next sprint starts rather than on its planned end, so the team's sprints never overlap. The sprint page and the team's Sprints section show a warning for overlapping sprints so they can be corrected at the source.

Who can do it. Members of the sprint's team, or of the team of teams it belongs to, who hold the Permissions.Iterations.Update permission. Holders of Permissions.Iterations.Administer can act on any team's sprints. Sprints whose Azure DevOps team is not mapped to a Wayd team cannot be started or completed. See Permissions.

Moving a sprint to another team. If Azure DevOps moves a sprint to a different team — for example after an area or iteration path changes — the sprint keeps the actual dates its team recorded. If it was open and the team it moved to already has an open sprint, the moved sprint is completed at the time of the sync, so the team still has one open sprint.

Every start, completion and reopening is recorded in the sprint's Activity.

Correcting Actual Dates

Past sprints — including every sprint from before Wayd recorded actual dates — have no actual start or end, and a team that forgot to press Start or Complete needs to fix the record afterwards. Correct Actual Dates in the sprint's Actions menu sets the actual start and end to the moments you choose, on any sprint, past or current. Clear a value to have the sprint follow its planned date again.

The same rules as Start and Complete keep the team's sprints in order:

• A start falls after the previous sprint's start and before the end of the sprint's last planned day. The team's first sprint can start up to 3 days before its planned start.
• An end falls after the sprint's start, recorded or planned.
• A sprint's end can't pass the next sprint's start, recorded or planned, so the team's sprints never overlap.
• A sprint left open (started but not completed) can't be followed by a sprint with actual dates.
• Neither date can be in the future.

Correcting neighbouring sprints together. The dialog also shows the previous and next sprints. To move this sprint's end past the next sprint's start — say the team finished a day late — correct the next sprint's start in the same dialog. Both are checked and saved together, and only the sprints you changed are saved.

A correction moves the sprint's commitment point, which changes its metrics, so each one is recorded in the sprint's Activity with the dates before and after. Who can correct is the same as who can start and complete.

Team Days Off

Some days the whole team is off for a reason no calendar knows: an offsite, a hackathon, a company event. Team Days Off in the sprint's Actions menu lists the sprint's planned days; tick the ones the team is off. Days outside the team's working days and holidays from its holiday calendar are already off: the list shows them greyed out, marked Holiday or Not a working day, and they cannot be ticked. A holiday such as Labor Day therefore never needs to be a team day off.

Team days off, holidays and time away are different things: a holiday comes from a calendar, a team day off is set on one sprint for the whole team, and time away is recorded on one person and applies on every team they are on.

The burn-down's ideal line stays flat on team days off, and with Team Capacity Management on nobody counts as working them: the sprint's capacity and its plan leave them out, and the plan marks them Team day off. A completed sprint's team days off are left out of what it delivered per person-day too. They are listed in the sprint's details, and each change is recorded in its Activity with the days added and removed and any change in how much of a day is off. Who can change them is the same as who can start and complete the sprint.

With Team Capacity Management on, a team day off can be part of a day: beside each day you tick, choose Full day, Half day or Hours, entered against the system's working-day length. A team day off is one share of everyone's day, so it never uses a person's own working day: 2 hours off an 8-hour system day is a quarter of everyone's day, which is an hour of a 4-hour part-timer's. A half-day offsite takes half of everyone's capacity that day, and the ideal line drops by half a day instead of staying flat. The plan reads the day Team off half day or Team off 2 h, and the sprint's details list how much of it the team is off. The sprint's capacity plan has a Team Days Off button too, which opens the same list. With the feature off, every day ticked is a whole day, and a part day set earlier keeps its share.

Sprint Type

Not every sprint is comparable with the team's others. An Innovation and Planning sprint is mostly planning and catch-up, and a hackathon, a hardening sprint or a sprint most of the team spends on holiday delivers far less than usual. Each sprint has a type that says whether it is comparable:

• Standard — a regular sprint, compared with the team's other sprints.
• Non-standard — not comparable. It is left out of the team's sprint metrics, which average velocity, predictability and say/do across the team's sprints, and listed there as left out. Its own metrics still show on its page as usual.

A sprint's type is worked out each time it is shown, from the first of these that applies:

1. Set by the team — the type the team chose with Sprint Type in the sprint's Actions menu.
2. From the PI iteration — the category of the PI iteration the sprint is mapped to: a Development iteration's sprint is standard, an Innovation and Planning iteration's is non-standard.
3. Default — standard.

So changing a PI iteration's category, or which iteration a sprint is mapped to, changes the type of a sprint that follows its mapping the next time you look. A type the team set holds whatever the mapping says: use it for a sprint with no PI mapping, a hackathon, a holiday sprint, or a team that runs its IP sprint at a different time. Choose Follow the planning interval to clear it.

The sprint's details show its type and where it came from, and a non-standard sprint has a Non-standard tag beside its state. Each time the team sets or clears the type it is recorded in the sprint's Activity. Who can change it is the same as who can start and complete the sprint.

Sprint Detail Page

The sprint detail page shows:

• Actions — Start, Complete and Reopen, when you may take them (see above), Correct Actual Dates, Team Days Off and Sprint Type. The menu is shown only to those who may manage the sprint
• Details panel — the Planned start and Planned end, the Actual start and Actual end the team recorded (— until recorded), the sprint's Length in days, its Type and where it came from, and its Team days off; the Team link under Relationships; and the sprint's Links
• Overview — a warning when the sprint's planned dates overlap a neighbouring sprint's, the timeline progress bar, and:
  • Capacity (with Team Capacity Management on) — the team's capacity for the sprint beside its scope. See Sprint Capacity below
  • Sprint Metrics (for Active/Completed sprints) — a progress row and a commitment row, with one switch between the team's estimate and counting work items, and the burn charts. See Sprint Metrics below
• Backlog — for an Active or Completed sprint, a toggle between Sprint Scope, every item that was in the sprint between its commitment point and its end, with how it came in (Entry) and what became of it (Outcome), its Original and Final estimate (Original SP and Final SP for a Story Points team: the estimate when it came in, and when it was last in the sprint), when it was Added to Sprint or Removed from Sprint, and its Current Status and Current Sprint, filterable by category; and Current Items, the work items in the sprint now, with Rank, Key, Type, Title, the team's estimate (Story Points, Effort or Size), Status, Status Category, Sprint, Parent Key, Parent, Assigned To, Project and Tags. A Future sprint shows its current items only
• Capacity (with Team Capacity Management on, for those who may view teams) — the sprint's capacity plan. See Sprint Capacity below
• Activity — the sprint's recorded history: what changed, who changed it, and when. See Activity Log

A Switch Sprint dropdown lets you quickly navigate between other sprints on the same team.

Sprint Capacity

With Team Capacity Management turned on, a sprint shows how much of its team's time it has and sets that beside its scope. Capacity is in person-days over the sprint's planned dates, from the people allocated to the team, after the holidays each person takes and their time away. A person-day is one system working day, so a part-timer with a shorter working day of their own counts for that share of one: half for a 4-hour day against an 8-hour one. The burn-down's ideal line weighs each person the same way.

At the top of the Overview, for a sprint in any state:

• Capacity — the delivery person-days: time in roles that count toward delivery capacity. The person-days time away takes show beneath it
• Planned or Committed — before the commitment point, the work in the sprint now; after it, the work committed, at its estimate then. Both are in the team's sizing method, or a count of work items
• Expected — what the capacity is expected to deliver: the work the team completed per person-day of delivery capacity over the completed sprints its team sprint metrics count, times this sprint's person-days. Sprints in another sizing method, and sprints nobody was allocated for, are left out. The sprints are the team's recent ones as of today, so a sprint some way back draws on fewer of them than the team had at the time, or none
• Over capacity — a warning when the planned or committed work is more than Expected, on a sprint that has not ended. A completed sprint shows the figures without it
• When there is nothing to compare with — time allocated only in roles that do not count toward delivery or all taken by time away, no completed sprints in the sizing method, or no one allocated during them — a line says so and nothing is expected
• A team with no one allocated for the sprint's dates shows none of these cards, so a team that does not plan capacity sees its Overview as before. Its Capacity section stays, to start allocating from

The Capacity section, for those who may view teams, shows the same figures above the sprint's capacity plan: the team's people against the sprint's weeks. Those who may change the team's allocations can edit it there, in percents or hours. To record a person's day off or a few hours away, use the calendar button beside their name: it is recorded once on the person and lowers their capacity in every sprint of every team they are on. Setting someone to 100% for the first week and 0% for the second changes those two weeks only, so their allocation after the sprint, and the next sprint's plan, stay as they were.

Capacity is worked out each time it is read. The ideal line on the burn-down reads the same allocations, holidays and time away.

Sprints List Page

The sprints list (Work Management > Sprints) shows all sprints across all teams in a grid with Key, Name, Team, State, Type, Start, End, Started and Completed, sorted by most recent start date. Started and Completed show the actual moments the team recorded, and are empty until the team records them.

Teams also see their sprints in the Sprints section of their detail page.

Active Team Sprint Card

If you are a team member of one or more teams, the Home page shows a My Team Sprints panel in the right column with an active sprint card for each of your teams (Teams only — Teams of Teams do not have sprints). The cards are sorted by team code.

Each card shows:

• Team code (links to the team page) and sprint name (links to the sprint page)
• Sprint health indicator
• Timeline progress — Days elapsed and percentage complete
• Predictability, Velocity, In Progress and Say/Do so far (see The Sprint Overview), four across on a wide card and two on a narrow one. Until the sprint has a commitment — before its commitment point, or while its history is incomplete — Completion Rate stands in for Predictability and Avg Cycle Time for Say/Do
• PI Objectives — If the sprint is mapped to a Planning Interval and the team has objectives, a card per PI shows the team's objective predictability: completed objectives over committed (non-stretch) ones (links to the team's plan review page)
• Burn-up — a small version of the sprint page's burn-up, in the team's sizing method, once the sprint has passed its commitment point and its history is complete

The panel is only visible if you have at least one active team sprint.

Sprint Metrics

Sprint metrics provide quantitative insight into a sprint's progress and delivery. Metrics are available for both individual sprints and PI iterations (which aggregate across all mapped sprints).

Metrics are measured in the team's sizing method. A sprint uses the sizing method of the operating model in effect on its planned start — Story Points, Effort, Size or Count — so a team that changes how it sizes keeps its earlier sprints in the old unit. A sprint whose team is not mapped to a Wayd team counts work items. One switch above the cards moves every card between the team's sizing method and counting work items; for a team that sizes by count the two are the same, so the switch is disabled.

Only requirement-tier work counts. Tasks are left out, since they break a story down and counting them would count the work twice, and bugs count only where the process puts them at the requirement level. This applies to the sprint page, the Home page's active sprint cards and PI iteration metrics alike.

The Sprint Overview

The sprint page's Overview shows two rows of cards, the burn charts, then where the sprint's commitment point and end came from and the time zone they're in. The Story Points / Count switch above the cards changes the cards and both charts together, and Wayd remembers your choice.

Progress — how the sprint's work is going:

Card	Shown	What it is
Days Remaining	Active	Days left in the sprint
Predictability	Once the sprint has a commitment	Velocity ÷ Committed, up to 100%. Finished work added after the commitment point counts toward it. Team avg beneath is the team's average
Velocity	Active, Completed	The work completed while in the sprint, including work completed and then moved out. Work moved to a Removed status in the sprint counts too, unlike most tools' velocity, and is shown beneath as "x as Removed". Team avg beneath is the team's average
In Progress	Active	Work in the sprint now in an Active status category, with its share of the sprint's work now
Not Started	Active	Work in the sprint now in a Proposed status category, with its share of the sprint's work now
Avg Cycle Time	Active, Completed	See below

Commitment — what the sprint committed to and what became of it, from Sprint Scope:

Card	Shown	What it is
Say/Do	Once the sprint has a commitment	Of the committed items, the share completed: their committed points ÷ all committed points. Say/Do so far while the sprint runs. Team avg beneath is the team's average
Committed		The work in the sprint at its commitment point, at its estimate then
Added		The work added after the commitment point, at its estimate when added
Descoped		See Sprint Scope
Re-estimated	When showing estimates and not zero	How much the work grew (+) or shrank (−) by being estimated or re-estimated after it came in: everything in scope now, less Committed and Added. Backlog → Sprint Scope shows which items, where Original SP and Final SP differ
Carried Over	Completed, or Active once there is some	See Sprint Scope
Unestimated	When showing estimates	Items in the sprint now with no value in the team's sizing method, shown as a warning if any exist. An estimate of 0 is an estimate, and another estimate never stands in: a Story Points team's item with only an Effort is unestimated

Predictability and Say/Do both compare delivery with the commitment, and read differently on purpose. Predictability asks whether the team delivered as much as it committed: finished added work stands in for committed work it didn't finish. Say/Do asks whether it delivered what it committed: only the committed items count. A team that swaps committed stories for new ones keeps its Predictability and loses Say/Do.

Velocity comes from the sprint's scope, so carried-over work stays in the measure after it has moved on. Until the sprint has a scope — before its commitment point, or while its history is incomplete — Velocity is measured on the items in the sprint now, the commitment cards and Predictability are hidden, and a warning says why. Sprint health — the tag in the page header and on the Home page's sprint card — measures delivery against the commitment: Velocity as a share of Committed, against the share the burn-down's ideal line expects done by now — so weekends, holidays and team days off expect no progress. Within 10 points is On Track, 10–25 behind is At Risk, more is Off Track, and delivering more than was committed always reads On Track. Work added or re-estimated after the commitment point doesn't count against the team, as on the burn-down's ideal line. Until the sprint has a commitment, health compares the work done with everything in the sprint instead.

Team Sprint Metrics

A single sprint says little about what a team typically delivers. Team sprint metrics put Velocity, Predictability and Say/Do side by side across the team's most recent completed standard sprints, with each one's average and its range, the lowest and highest sprint. The spread matters as much as the average: a team that delivers between 38 and 44 points plans differently from one that delivers between 10 and 70.

They use the same definitions as the sprint page: each sprint's values come from its own Sprint Scope, so a number here is the number on that sprint's page. They are worked out each time they are shown and never stored. An average is the mean of the sprints' values, so every sprint counts the same whatever its size.

Which sprints count. Wayd takes the team's completed sprints from the most recent back until it has enough, and leaves out:

• Non-standard sprints — see Sprint Type.
• Sprints with incomplete history — a workspace holding the sprint's work has not had its history read in full, so its figures are unreliable. A full sync of the connection completes it.
• Sprints with nothing committed — nothing was in the sprint at its commitment point, so it has no Predictability or Say/Do.

How many sprints is the organization's sprint window, 7 unless an administrator changed it under Settings > System > Sprint Metrics. It is the same for every team, so their figures compare. A team with fewer usable sprints is measured over those it has; Wayd looks back no further than three times the window.

Where they show:

• The team's Overview — three cards, in the team's sizing method, over the organization's sprint window. Select one to open the report.
• The team's Sprint Metrics report, under Reports on the team page — the averages and ranges, each sprint's own values with a link to the sprint, and a Left out list giving each passed-over sprint's reason. It opens at the organization's sprint window every time; Over the last runs it over another, from 3 to 12 sprints, for that visit only. The Story Points / Count switch is the sprint page's, and Wayd remembers it.
• The sprint page — Team avg beneath the sprint's Predictability, Velocity and Say/Do: the team's average over its most recent sprints as of now, whichever sprint you are looking at. A non-standard sprint shows none, since it isn't comparable with them.

When the team changed its sizing method. A sprint keeps the sizing method it was planned in, and estimates in different units are never averaged. The averages are in the team's sizing method now. A sprint measured in an earlier one still counts by work items, and the report shows — for it by estimate and says how many sprints that affects. Switch to Count to compare every sprint. The team's Overview says how many of the sprints its averages cover, and counts work items until the team has a sprint in its new sizing method. On the sprint page, Team avg shows by estimate only when the sprint and the team's averages are in the same unit.

Average velocity is shown rounded to a whole number.

Burn-up and Burn-down

Under the cards, two charts show the sprint day by day, from the same work item history as Sprint Scope:

• Burn-up — Scope, the work in the sprint, and Completed, the part of it in a Done or Removed status category. Work added after the commitment point steps scope up, descoped work steps it down, and re-estimating an item moves it on the day it was re-estimated. Work completed and then moved out of the sprint stays in both lines.
• Burn-down — Remaining (scope less completed), and a dashed Ideal line from the committed work at the commitment point to zero at the sprint's end. It falls evenly across the team's working days and stays flat on the rest: days outside its working days, holidays in its holiday calendar, and the sprint's team days off. A day the commitment point or the end cuts in part counts in part, and so does a part team day off: half a day off drops the line by half a day. If none of the sprint's days is a working day, the line falls evenly over every day instead. With Team Capacity Management turned on and people allocated to the team, a day is weighed by how much of their time is there: the time allocated in roles that count toward delivery capacity, less the holidays of the calendar each person follows and their time away. The line then drops by that share of a normal day, so a holiday three of eight people take drops it by five eighths, and one of four people away for half a day drops it by seven eighths. The team's own calendar plays no part on such a day, since each person's holidays come from the calendar they follow, or the system default; days outside the working week stay flat, and a team day off takes its share of what is there. A day nobody is allocated on, and every day of a team with no allocations, is drawn as before. The ideal line is worked out each time it is read, so a later change to holiday calendars, allocations or time away redraws past sprints as well as current ones. Reopened work counts as remaining again.

Each chart has a reading at the commitment point, at the end of each day in the team's time zone, and at the sprint's end — or now, for a sprint still running, whose lines stop there. A day's changes show on that day. Both charts span the whole sprint, so their days line up, and they agree with the scope cards: at the start, Scope equals Committed; at the end, Completed equals Velocity. While the sprint's history is incomplete the charts are hidden.

Correcting the commitment point. The commitment point is the team's recorded start, so committed points are the estimates at that moment. If the team was still sizing work after pressing Start, correct the start to when sizing finished. The date pickers in Start, Complete and Correct Actual Dates use your time zone and name it, along with the team's when it differs. Azure DevOps shows work item history in your profile's time zone too.

Metric Definitions on PI Iterations

PI iteration pages measure the items in each mapped sprint now:

Metric	Formula
Total	Sum of every work item's estimate in the team's sizing method (or the number of work items)
Completed	Items where status category is Done or Removed
In Progress	Items where status category is Active
Not Started	Items where status category is Proposed
Completion Rate	(Completed / Total) × 100
Velocity	Completed estimate (or the number of completed work items)

Completed includes both Done and Removed status categories: removed work has been resolved, even if by removal from scope, and is no longer in progress.

Cycle Time in Sprint Context

Average Cycle Time is only calculated from work items that:

1. Have a Done status category (not Removed)
2. Have both an Activated Timestamp and a Done Timestamp
3. The Done timestamp is after the Activated timestamp

Per item: Cycle Time = Done Timestamp − Activated Timestamp (in days)
Sprint average: Sum(all item cycle times) / Count(eligible Done items)

Items that were moved directly to Done without being Activated, or items that were Removed, are excluded from the cycle time calculation.

For a deeper analysis of cycle time patterns over longer periods, use the Cycle Time Report on individual team or employee pages.

PI Iteration Metric Aggregation

When viewing a PI iteration, metrics are aggregated from all mapped team sprints, and from the planning interval's Kanban teams, which are measured over the iteration's dates:

• Counts are summed across all sprints (Total, Completed, In Progress, Not Started, Unestimated). Kanban teams add to Completed, In Progress and Unestimated, but not to Total or Not Started, which come from sprints only
• Estimates are summed only when every sprint and Kanban team is measured in the same sizing method. When teams size in different units, estimates are never added together: the iteration's totals are counts, and each team's card shows its own unit
• Average Cycle Time is the total cycle time of every eligible item across the sprints and Kanban teams divided by the number of those items, so a sprint with more completed items weighs more
• Team Count and Sprint Count show how many teams (including Kanban teams) and sprints are included

Sprint Scope

The metrics above count what is in the sprint now. An item carried over to the next sprint disappears from them, and an item added mid-sprint looks as if it was planned. Sprint Scope answers what the team committed to and what became of it, from each work item's history: where it was, its status and its estimate at every moment since it was created. History comes from the Azure DevOps sync.

Scope is measured between the sprint's commitment point — when the team started it, or the end of the commitment grace period after its planned start — and its effective end — when the team completed it, or the end of its last planned day. The page says which each one is, and shows their times in the team's zone. Only requirement-tier work counts: tasks are excluded, and bugs count only where the process puts them at the requirement level. A change of work type out of that tier counts as leaving the sprint, and one into it as entering.

Each item that was in the sprint has one way in and one outcome:

Category	Rule
Committed	In the sprint at the commitment point. An item taken out and put back is still committed.
Added	Entered the sprint after the commitment point and before the effective end.
Completed	In a Done-category status when it was last in the sprint — at the effective end, or when it left.
Completed as Removed	Reached a Removed-category status while in the sprint. It counts as completed and the team gets credit, and is shown as a sub-count of Completed.
Carried Over	Unfinished and still in the sprint at the effective end, or moved to the team's next sprint on or after the sprint's last day.
Descoped	Unfinished and taken out of the sprint before its last day — or on it, for somewhere other than the team's next sprint.
Remaining	Unfinished and still in a sprint that has not ended yet.

Work finished before the sprint isn't in its scope. An item already Done or Removed before the team started the sprint — or, if the team didn't press Start, before the first planned day — counts in no category, even if it was left in the sprint: no work on it happened there. Work finished on the first planned day still counts when the team didn't press Start, since the commitment point comes at the end of that day. If such an item is reopened while in the sprint, it counts as Added from then on.

The sprint's last day is its last planned day, or the day the team completed it if that came first. So a team that plans the Friday before a Monday holiday — moving its unfinished work to the next sprint and starting it that afternoon — carries that work over rather than descoping it.

Say/Do is the committed work that was completed, divided by the committed work. Work added after the commitment point doesn't count either way. In estimates, both sides use the estimate each item had at the commitment point, so re-estimating an item during the sprint doesn't move the ratio. While the sprint runs it shows as Say/Do so far.

Like the metrics, scope is measured in the team's sizing method, with a selector to count work items instead. An item's estimate is the one it had when it came in for Committed and Added, and the one it had when it was last in the sprint for the outcomes. A sprint whose team is not mapped to a Wayd team uses the system default time zone and grace period and counts work items, and the page says so.

Scope is worked out each time it is shown, never stored. A late sync, a corrected actual date or a full sync changes past sprints' scope the next time you look.

Deleted work items don't appear. A work item deleted in Azure DevOps is deleted from Wayd with its history, so it drops out of every sprint's scope. To take work out of a sprint and keep the record, move it or set it to a Removed status.

History incomplete. Until a workspace's history has been read through to the end once — the first sync after upgrading, or after the workspace is added — its history is missing its most recent changes. A sprint holding work from such a workspace shows History incomplete — run a full sync instead of its scope. A full sync of the connection completes it; Current Items still shows what is in the sprint meanwhile.