Process patterns: what are "composites"?

The key to defining the task structure in a process definition is the task pattern. Task patterns consist of prototype tasks, optionally contained in a prototype project. Here's an example:

This is the task pattern for a "Feature" in the FDD process and it results in the creation of a set of subtasks and artifacts when the Feature pattern is "instantiated". This is quite a simple pattern and it doesn't include any composite tasks, which are structures to allow multiple tasks, optional tasks and iterations of tasks (repeated tasks that follow on one after the other). It is composites that allow arbitary process diagrams, drawn say using UML's activity diagram format, to be translated into xProcess processes. Here's an example of a task pattern, this time shown in the Hierarchy Diagram view, which does contain a composite. It's the "Feature Set" pattern from the same process.

The composite task in this example is called "Features: $Name$" (this is a pattern so the $Name$ will be substituted by the user supplied name when the pattern is instantiated). It contains a choice of 3 patterns: "Defect", "Feature" and "Task". Any of these patterns may be instantiated multiple times within the composite task.

Composite tasks are parent tasks, in other words they do (or will) contain child tasks, and they also define constraints on what type of child tasks can be created through the patterns they contain. In the latest version of xProcess composites can be instances (only one pattern can be instantiated in the composite), collections (an arbitrary number of patterns can be instantiated in them) or iterations (similar to collections but each pattern will be constrained to start after previously instantiated tasks have completed). Composites contain one or more patterns which define the options available when creating new tasks in the composite. In the example above, Defects, Features or Tasks can all be instantiated within the composite.

So the composite mechanism gives the Process Engineer the ability to define task patterns with loops, sequences and optional paths. More or less any pattern that can be represented in a flow chart or activity diagram can be created in an xProcess pattern by using composites. Composites go further though. Because of xProcess' support for top-down estimation, composites have their own estimates and resource requirements so that they can be scheduled even before the detailed decisions about how many tasks, iterations or options have been made.

To understand how these top-down estimates work in practice, see this blog article: Latest Patterns for Scrum which shows how the top-down estimate for a Sprint is used for scheduling resources, up to the point that all the backlog items have been created within it.

Footnote Question (for the techies among you!):
Are all parent tasks also composites as well as vice versa?
Well firstly all composites are parent tasks. Even if they as yet contain no child tasks they are classified as parent tasks because they allow task patterns to be instantiated in them. On the other hand parent tasks are only composites if they contain a set of patterns. This set defines the patterns that can be instantiated in the composite /parent task. So a parent task without such a set of patterns is not a composite and (in version 2.x) any non-hidden task pattern maybe instantiated in it.
[Note in version 3 this behaviour is likely to be changed, effectively removing any distinction between parents and composites. If the parent task does not contain any patterns, no patterns will be able to be instantiated in it. This will allow Process Engineers to create project patterns where, for example, certain tasks have a fixed set of children which cannot be added to.]