Modeling your own processes

Modeling your own processes#

When you map a process onto Allegra for the first time, the question of the best way to model it often arises. The following notes help with the typical decisions.

Item attribute vs. item type#

Depending on the use case, you work with different kinds of items. You model the kind of an item in two ways:

  • via a dedicated item type

  • via an item attribute (selection list) as a discriminator

For filtering and searching, both solutions are equivalent. Dedicated item types, however, offer additional possibilities:

  • dedicated forms

  • dedicated workflows

  • dedicated access restrictions

As a rule, it is more advantageous to create dedicated item types and do without discriminator attributes. If you have very many kinds of items that must also be flexibly extensible, the discriminator method is preferable.

Modeling projects#

What a “project” is varies greatly from one discipline to another. In Allegra, you model projects either as workspaces or as items.

Arguments for modeling as a workspace:

  • The project is likely to have several hundred items.

  • The project runs for several weeks to months.

  • You want fine-grained control over access to project items.

  • The project is divided into phases or has several releases.

Arguments for modeling as an item:

  • The project comprises fewer than 50 items.

  • The project runs for only a few weeks.

  • There are many similar, recurring projects.

Hint

Workspaces have no freely configurable attributes. If you need some, create a proxy item at the top project level (item type, e.g., “Project proxy”) that carries the desired attributes of the project.

Modeling workflows#

You model workflows either via a sequence of states or via a series of child items.

Note

A child item is a subordinate item (also called a sub-item or subtask). The associated superordinate item is called the parent item.

Child items keep the total number of states manageable. If a workflow needs significantly more than ten states, it is better to use child items with their own workflow.

Releases, sprints and backlogs#

You structure workspaces (projects) over time via phases. Allegra knows three kinds of phases:

  1. Releases (milestones, versions)

  2. Sprints (iterations)

  3. Backlogs

Each phase comes with its own logic: releases distinguish between “in progress” and “released”, sprints carry a capacity in story points, and backlogs sort items by business value.

Contents