Workflow
All main project artifacts have their own lifecycle (LC), which is used to manage these artifacts. Primary requirements (Issues) are created, elaborated, implemented, tested, and so on. Each status (stage) is tied to the production technology. System requirements, in turn, are developed, approved, agreed, and then implemented. These statuses are tied to requirements development and documentation.
The following can be associated with each status:
- a color, which is used when coloring the background of the status text;
- form field settings — the ability to override the visibility and requiredness of fields on the artifact edit or create form;
- system actions — internal triggers that fire when this status is assigned to a project artifact.
The system tracks the time an artifact spends in each state. The "Time in state" field shows this time and can be displayed in lists or on boards. The system also calculates the total lifecycle duration, so that you can find out, for example, how long a particular document section was developed. In some states the team is not working with the artifact, for example while waiting for approval from the customer. So that the waiting time does not distort the lifecycle duration, it can be excluded from the calculation by selecting the checkbox "Exclude time spent in this state from the resolution time".
The base state lets the system understand which part of the lifecycle the artifact is in — it has just been created, it is in progress, or work on it is completed — without further detail. Base states are used in system actions, for displaying artifact UIDs, and for building cross-project boards.
Rules for moving from one state to another are defined by "Transitions". In the transition settings you can specify whether to ask for the reason for the status change, which Roles may perform such a transition, and which preconditions must be met. You can also attach system actions, or clearing of field values, to specific transitions.
You can develop a PHP script to set as a precondition for a transition. If the condition is met, the script must return true, if not, then false. Before the transition is performed, the system runs the script. Depending on the result, the operation either succeeds, or the system reports that a precondition for the transition was violated. The functionality is available if you have a license for the "Script automation" module and configured rights for this module. Script execution results can be tracked in the Administration section, in the PHP scripts module.
Additional parameters can be set for Issue and Enhancement states:
- Tasks — the list of Task types specified here is characteristic of the given stage; for example, when an Issue is decomposed into Tasks, the system suggests exactly these Task types.
- Work-In-Progress limit — limits used in the Kanban process; they signal the team about the maximum number of unfinished cards in this state.
- Artifacts — the system suggests creating artifacts of this type in this state.
- Artifacts can be created directly in this state — the option controls whether an artifact can be created in the given state. On boards, users can add cards only in those columns for which this flag is set.
System actions for primary requirements (Issues and Enhancements) can be extended using automatic actions. These actions let you change Issue attributes, reset their values, and create Tasks or comments when the status changes, when attribute values change, when comments are created, or on a schedule.
Lifecycle differences for different types of one artifact
Bugs or Enhancements are different types of one artifact (an Issue or a user story); Tasks, Requirements, and other project artifacts also come in different types. Different lifecycles (status models) can be configured for different types of one artifact.
Differences in the lifecycle can be minor or substantial. For example, if a Bug must pass an additional reproduction stage performed by a tester, that lifecycle difference from the other Issues is minor. On the other hand, Requests processed by support and Issues implemented by the development team have completely different lifecycles.
| Degree of lifecycle difference | Ways to configure |
|---|---|
| Minor differences | In the transition settings you can use predicates "Type: Bug" in order to allow moving artifacts of a specific type to a specific state. |
| Substantial differences | As a rule, substantial lifecycle differences are tied to the different processes the artifact is involved in. For example, processing Requests (user requirements) on the first line of support also requires additional configuration of the software interface. For this reason, different lifecycles for user requirements are implemented as different processes (projects). Such processes and projects can be combined into a shared management space using a Project program or a project Portfolio. Thus, all user requirements are visible at the Project program level, and at the subproject level (processes that differ) you can manage the lifecycle of a specific user requirement depending on the processing stage: support or implementation. |
Lifecycle analytics
The "Cycle time breakdown..." module lets you analyze how a subset of artifacts spends time in various states and identify the time spent in a state, the percentage of time spent relative to the total cycle time, and so on.
System actions
System actions can have parameters, whose meaning is given in the table below.
For system actions you can set the flag "Notify the user before performing the action", which reports in advance that, when a transition is performed or the state changes, this system action will be executed. For example, this is useful when performing cascading actions, such as changing the statuses of parent or child Requirement sections, or of test or operational documentation.
Issues and Enhancements
| Action name | Purpose and usage notes |
|---|---|
| Change the state of the source Issues |
If you link a story, an Issue, or a Request to one or more Issues using a link of type "Implementation", this system action lets you control the state of those Issues. As the parameter, specify the reference name of the state to which the source Issues must be moved. |
| Implement in project |
When the system action is executed, a copy of the Issue, story, or Request is created in the target project. A link of type "Implementation" is established between the Issues. The code name of the target project where the copy must be created is specified in the system action parameters. You can specify several code names separated by a comma. In this case several implementations of the source Issue are created. |
Tasks
| Action name | Purpose and usage notes |
|---|---|
| Change the state of the story or Issue (by the first transition) if all Tasks of the current stage have one state |
For example, a story or an Enhancement is at the development stage. The story is decomposed into testing Tasks, documentation Tasks, and so on. The story must be moved automatically to the testing stage if all Tasks related to development are completed. Task types are bound to a stage (a state of the story or Enhancement) on the Enhancement status change form:
|
| Move the linked artifact to the next state |
The linked artifact can be a business or system Requirement, a test scenario, or a technical documentation section. This action automates changing the state of the linked artifact, for example when a Task is completed. Application variants:
|
Requirements
| Action name | Purpose and usage notes |
|---|---|
| Mark documentation of the linked function as outdated |
One or more functions can be linked to a Requirement. This means that this Requirement clarifies (specifies) these system functions or product features. Test scenarios or operational documentation sections can also be linked to functions. This system action lets you mark the documentation linked to the functions as outdated. |
| Set the state to that of the parent section |
Changes the Requirement state to the state of the parent section, that is, the previous one in the Requirements document hierarchy. WARNING: The state will not change if the corresponding transition is missing in the settings of the "Requirement states" module. |
| Set the state of parent pages to the same state as the children |
Changes the state of the parent Requirement to the state specified in the system action parameters. The system action runs for a Requirement on the condition that ALL of its child sections (at any nesting level) are in the state and/or have performed a transition with this action. As the parameter you can specify the name or the code name of the target state. WARNING: The state will not change if the corresponding transition is missing in the settings of the "Requirement states" module. |
| Set the state of parent pages to the one specified in the parameters |
Changes the state of the parent Requirement to the state specified in the system action parameters. The system action runs for a Requirement on the condition that AT LEAST ONE of its child sections (at any nesting level) is in the state and/or has performed a transition with this action. As the parameter you can specify the name or the code name of the target state. WARNING: The state will not change if the corresponding transition is missing in the settings of the "Requirement states" module. |
| Set this state for all child pages |
Changes the state of all child Requirements (at any nesting level) to the state of the parent. WARNING: The state will not change if the corresponding transition is missing in the settings of the "Requirement states" module. |