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.