Work Queue

If deliverables are ill-defined, you need to allow time to do everything. Therefore: produce a schedule with less output than you have input. Use the list of Implied Requirements (really just names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority items.

## Relationships

### To be applied before

* problems with Completion Headroom lead to a Work Queue.
* Work Queue defines initial targets for Size The Schedule.
* Implied Requirements and Work Split are inputs for a Work Queue.

### To be applied after

* Work Queue is an input for an Informal Labor Plan and a Recommitment Meeting.

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

... Implied Requirements suggest deliverable program enhancements which will have various necessities, dependencies, risks and rewards. Deliverables may be ill-defined, being represented more by a vision or desire than by anything concrete or measurable.

## Problem

**It is difficult to do linear, monochronic scheduling in light of Implied Requirements.**

If we were to work up a conventional schedule we would probably begin with a block of requirements analysis for each item. From these would be hung blocks of specification, design, implementation and eventually integration and testing. Add to this some wild guesses and a few ordering constraints and, presto, thirty feet of diagram saying what will be finished when and by whom. Such a document takes on a
life of its own striking fear in developer’s hearts and generally distracting everyone else from the real scheduling task which is to get better input, not larger output.

## Solution

**Produce a schedule that is simply a prioritized list of work. Use the list of Implied Requirements (really just names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority items.** When work can be factored from two or more entries, go ahead and do so giving the common element a name that establishes its worth and implies its implementation precedence.

## Discussion

*Example:*

1. Settlement-Date Positions
2. Settlement-Date Based Tax Reports
3. Trade vs. Settlement Accounting Preference by Portfolio

Be prepared to reorder this list as unforeseen interactions surface or business realities demand new priorities. Remove work from the list as it is completed. Observed defects is not enough to return completed work to the list. However, independently scheduled repair activity may uncover omissions that are more appropriately removed from defect tracking and scheduled in competition with all of the other work on the **Work Queue**.

A version of this pattern first appeared in [Cunningham1996]. The pattern is similar to the later SCRUM pattern “Backlog” [Beedle1999, 643-644], which is summarized in [Rising2000, 146]:

> To organize the work remaining on a project, maintain a prioritized list, the Backlog. The list is dynamic and updated at the end of each Sprint.
>
>

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html