State Flow
The life cycles of some of the task types are identical by default for the facilitation of the workflow, though separate state model records are added for each of them. Task states in the SDLC application are sequential. This means that default state models do not allow skipping states or returning to them after transitioning to the next ones.
You can see the state model of a specific task type on its form. This state model is applied to the tasks of this type in which a project is not specified.
- Note that if more than one state model suits a task by Table and Condition, the system behavior may differ on the task form and the project board. To avoid this situation, we recommend you to create only one state model for each task type in each project and specify this state model when you add a State Model in Project.
- By default, the "out-of-the-box" application includes an inactive state model for the SDLC Task (pda_backlog_item) table. Do not activate it, specify on task type forms and in projects. The use of this state model will result in errors.
If necessary, you can customize the SDLC Task state models.
SDLC task state flow
- Epic, User story, Defect, General task
- Feature
- Design story
- UX research
- Test case
- Automated test
- Documentation task
| Order | State | Description |
|---|---|---|
| 1 | New | The task goal and input data have been determined. |
| 2 | Backlog | The task has been analyzed, estimated, and the work on it has been planned. |
| 3 | Development | The assigned user has started working on the task. |
| 4 | Review | The work on the task has been completed and the results are under evaluation. Corrections are done if necessary. |
| 5 | Testing | The task is being tested. |
| 6 | Done | The task is completed and ready for release. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | Funnel | The process of initial prioritization and structuring of the feature, evaluation of potential business value and compliance with the product strategy. |
| 2 | Backlog | Determination of approximate implementation terms, estimation of the resources required for the implementation, the completion of the prioritization. |
| 3 | Analysis | Decomposition of the feature into specific implementable tasks ready for development. |
| 4 | Awaiting implementation | The analysis has been completed and the feature can be taken to work according to the project priorities. |
| 5 | Implementation | Development, testing, and preparing the feature's tasks for the release. |
| 6 | Release | Preparation and publication of the release, creation of the documentation and marketing materials. |
| 7 | Completed | The feature has been successfully released. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | New | Basic design story requirements have been determined. |
| 2 | Analysis | The design story is under analysis: the assigned employee validates the completeness of the description and adds use cases and other artifacts if required. |
| 3 | Backlog | The design story is moved into the backlog and can be taken to work. |
| 4 | In progress | The assigned user has started working on the design story. |
| 5 | Internal review | The results are under evaluation by the designers. Corrections are done if necessary. |
| 6 | External review | The results are under evaluation by the specialists of other directions from the product team. Corrections are done if necessary. |
| 7 | Awaiting development | The design story has passed the reviews and awaits the development of the task that it supports. |
| 8 | Development support | In the course of the supported task development, the designer controls the implementation of their work results. |
| 9 | Completed | The task supported by the design story is completed, and the designed custom solution has been applied. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | New | Basic UX research requirements have been determined. |
| 2 | Analysis | The UX research is under analysis: the assigned employee validates the completeness of the description, creates hypothesis and plans of work. |
| 3 | Backlog | The UX research is moved into the backlog and can be taken to work. |
| 4 | In progress | The assigned user has started working on the UX research. |
| 5 | Review | The results of the UX research are presented to the stakeholders. Further work based on the research results is planned. |
| 6 | Completed | The UX research is completed. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | New | The task for which a test case needs to be developed has been determined. |
| 2 | In progress | The assigned user has started working on the test case. |
| 3 | Awaiting review | The work on the test case is complete. The results are awaiting review. |
| 4 | Review | The results are under evaluation. Corrections are done if necessary. |
| 5 | Completed | The test case has passed the review and testing can be done based on it. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | New | The task for which the test coverage needs to be developed has been determined. |
| 2 | In progress | The assigned user has started working on the automated test. |
| 3 | Awaiting review | The work on the automated test is complete. The results are awaiting review. |
| 4 | Review | The results are under evaluation. Corrections are done if necessary. |
| 5 | Awaiting release | The automated test has passed the review and awaits the publication of the related release. |
| 6 | Completed | The release for which the automated test was developed has been published. This is the final state that does not allow any further transitions. |
| Order | State | Description |
|---|---|---|
| 1 | New | The functionality that requires documentation or the documentation that needs improvement has been defined. |
| 2 | Backlog | The work on the documentation task has been planned. |
| 3 | In progress | The assigned user has started working on the documentation task. |
| 4 | Expert review | The results of the documentation task are ready for a review by a subject-matter expert. The subject-matter expert evaluates the completeness and validity of the created or improved documentation. Corrections are done if necessary. |
| 5 | Peer review | The results of the documentation task are ready for a peer review. Other technical writers evaluate the compliance of the created or improved documentation with the style guide and grammar rules. Corrections are done if necessary. |
| 6 | Ready to publish | The results have passed the reviews and await publication. |
| 7 | Published | The results have been published and are now available to users. This is the final state that does not allow any further transitions. |
The final stage in a task lifecycle could be its cancellation or inclusion in a released release.
A task can be canceled from its form or the task board. When a task is canceled:
- its state becomes read-only,
- it becomes inactive,
- the Canceled label in Russian appears on its form,
- it disappears from the task board.
If required, you can reopen the task on its form after the cancellation.
When a release that includes the task moves into the Released state, the Released marker is added to the task. Such a task becomes inactive and read-only except for the Release field. The Released label in Russian appears on its form. You can leave work notes in its Activity Feed. The task will stop being Released if you change the value of the Release field.
Subtask state flow
| Order | State | Description |
|---|---|---|
| 1 | New | The subtask goal and input data have been determined. |
| 2 | In progress | The assigned user has started working on the subtask. |
| 3 | Done | The subtask has been completed. This is the final state that does not allow any further transitions. |
The final stage in a subtask lifecycle can be its cancellation or movement into the final state (Done by default).
A subtask can be canceled from its form. When a subtask is canceled:
- its state becomes read-only,
- it becomes inactive,
- the Canceled label in Russian appears on its form,
- it disappears from the list of subtasks of its parent task on its card on the task board.
If required, you can reopen the subtask on its form after the cancellation.
Classification relatively to boards
Relatively to boards, the states can be divided into the following categories:
-
States before the board – the state options whose columns are inactive, and whose Order is lower than the First board state order.
-
Board states – the state options whose columns are Active. Among them, you can distinguish:
- The First board state – the state option that corresponds to a column with the lowest Order among the active columns.
- States before the first and final ones – the state options corresponding to the board's active columns excepting the first and fnal board states.
- The Final board state – the state option that corresponds to a column with the highest Order among the active columns.
-
States after the board – the state options whose columns are inactive, and whose Order is higher than the Final board state order.
State displaying
The SDLC application contains a logic, according to which only tasks of certain types are displayed in its' different parts. The available states' selection when you add a task is also different depending on the place of task creation. Use this information if you have issues related to state displaying in the application.
For a state column to be displayed on a task board, make it Active.
Task creation
| Where you add a task | Avaialble task types | Avaialble states |
|---|---|---|
| The form of an SDLC Task (pda_backlog_item) child table | Any | Any |
| The SDLC Task related list on the Product (pda_product) form | Task types of the 1-3 levels | Any |
| The SDLC Task related list on the Project (pda_project) form | Task types of the 1-3 levels added to the project | Any |
| Task board | Task types of the 1-3 levels added to the project | States before the board, board states |
| Add tasks to board widget, Sprint planning widget | Task types of the 1-3 levels added to the project | States before the board, the first board state |
Task list filters in widgets
The Add task to board and Sprint planning widgets have a list of tasks with preconfigured filters. To learn the tasks in which states are dispalyed in these filters, read the articles about the widgets:
- Add Tasks to Board for Kanban projects
- Sprint Planning for Scrum projects