A work-back schedule is a schedule created by taking a final deadline and “working backwards” in order to determine intermediate deadlines.

For example, suppose we want our feature to go out in the last Windows Insider build of the year, so that we can gather results during the holiday break. The Windows Insider team tells us that their last build of the year will the one built on, say, Friday, December 16.

Now we start working backward.

Suppose we are following the hypothetical RI schedule I used when discussing train jargon, and our feature is being developed by team A2. According to that schedule, changes from branch A are pushed to the trunk every Monday, and changes from branch A2 are pushed to branch A on Tuesdays and Thursdays.

Therefore, in order for the feature to reach the trunk by Friday, December 16, it must be in branch A by Monday, December 12. And in order for the feature to be in branch A by Monday, December 12, it must be in branch A2 by Thursday, December 8.

Suppose you decide to leave a week to let the feature bake; during that week, you fix bugs and possibly even disable some parts of the feature if they don’t look like they’re going to be stable enough to go out to Insiders. (Using the jargon: Those parts of the feature didn’t land.)

Okay, so that means that all the feature work needs to be complete by Thursday, December 1. And then you look at your estimates for each of the tasks that need to be completed, subtract them from December 1, and come up with a schedule that sets the deadline for each of the tasks, so that everything gets done in time.

That is your work-back schedule, also called a work-back plan.

Microspeak naturally abbreviates the term and just calls it a work-back. It is common to omit the hyphen and call it a workback.

From that abbreviation, we then get derived terms. In the example above, somebody might say, “The Windows Insider release snaps on December 16, and if you work it back, that means we need to make a go/no-go decision on December 8.”