Work Queue

First described in WardCunningham's EpisodesPatternLanguage.

Sort the Stories to be done by priority. Commit small groups to whole stories. Individuals will then plan their own activities to address those commitments near the top of the list. Reorder the list as new requirements become apparent or priorities change. Split requirements, if necessary, to meet schedules.

Compare this to ReleasePlan which produces regular, team-wide completion events. Prefer release plan when such events would be motivating for either developers or customers. Use work queue when requirements are unbounded or continually in flux.

[Discussion moved to PairProgrammingDuration, to make it more visible.]

Episodes is less strict than XP. It suggests that the people who commit to a work queue item (ImpliedRequirement?) work out an InformalLaborPlan? on their own. The scheme encourages PairProgramming by not assigning responsibility or ownership to individuals. Kent and Ron and James have shown that more coercion is not out of line. -- WardCunningham

Sounds similar to a ScrumBackLog?

Somehow in the refactoring, some of the detail about WorkQueue seems to have been lost. Maybe that was because it specified a number of DoIt twists on the more generic WorkQueue format. The things that were important to us about the work queue (as opposed to a project plan) were:

Forces a simple, serial approach to project planning
Based entirely on Uninterrupted Days to Completion, none of this "percent complete" nonsense
Reinforces the idea of building in HorizontalStripes -- no-one is done with a row until the whole system works end to end
One single document, usually a single page, that is useful to developers, project managers, and business customers

-- BillBarnett

A related issue is to ScheduleToUnblockOthers.