Version 1.8.0
To perform a migration from the previous version to 1.8.0, you need to launch the Migration script for SDLC 1.8.0 version script after the import of the SOP file with the application update. Details are available in the article about the application deployment.
In the new version, we introduce a change that will allow you to configure state models in projects for specific task types. We have updated the logic of the majority of application elements to implement this change.
Other important changes are the creation of five new third-level task types, update of the Feature state model, and fixes to the SDLC-ITSM integration.
Configuration of default state models for task types and in projects
We have added the ability to configure state models for each task type in project. The configuration of task state models is a flexible tool that will allow you to adjust the application for projects with different development approaches, while keeping the ability to reuse and not interfering with the scalability of the projects.
With this update, you will be able to use existing state models to speed up the launch of new teams and increase efficiency, since now the system can provide the actual state model used by the team instead of offering only a fixed "out-of-the-box" state model. Moreover, we have preserved the agreement among state models throughout all the application tools: a configured state model is applied to task boards, task planning widgets, and reports.
The list of updates:
- State models in projects
- Replacement of the Canceled and Released states with similar markers
- Update of column creation rules
- Update of project creation and completion
- Update of task boads, preview widget, and task creation from related lists
- Update of the Add tasks to board and Sprint planning widgets
- Configuration of burnt state in the chart and release update
- Update of task forms logic
State models in projects
We have created the State Models in Project (pda_state_model_project) table that stores information about the state models used for each task type in each project. When a task type is added to a project, the system checks if there is an existing state model in the project and, if there is none, automatically creates a new record.
- The State Models related list has been added to the Project (pda_project) form. It shows the state models applied to the task types added to the project.
- The State model field has been added to the Task Type (pda_task_type) table. It contains the state model applied to the tasks of this type that are not related to a project.
- Default state models have been created for all "out-of-the-box" task types. When a custom task type is added, a default state model is created automatically.
- Users with the pda_admin and pda_user roles can now read records of the State Model (sys_state_model), State Transition (sys_state_transition), and Choice Option (sys_choice) tables.
If no state model is specified for a task type in a project, in this project:
- On the board: all state transitions are allowed for this task type.
- On the task form: if there is a suitable state model for this task type, it is applied. If there is no such state model, all transitions are allowed.
Read more in the documentation.
Replacement of the Canceled and Released states with similar markers
The Canceled and Released states have been deleted from the state models of all task types. Instead, we have added columns of the True/False type called Canceled and Released that allow you to move a task into one of the possible final states without changing the current state choice option.
Cancel a task
You can cancel a task from its form using the new Cancel task UI action located in the burger menu . Alternatively, you can cancel it from the task preview on the task board by clicking the icon. 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 from its form using the new Reopen task UI action located in the burger menu .
Release a task
When the related release moves into the Released state, the Released marker is added to the release tasks. Such tasks become inactive and read-only except for the Release field. The Released label in Russian appears on their forms. You can leave work notes in their Activity Feed. The task will no longer be considered Released if you clear or change the value of the Release field.
Read more:
Update of column creation rules
We have changed the business rule that creates task board columns: now, columns are only added for choice options with unique Value created for the third-level task types. If the Value is identical for some of the states, only one column is added for them. If one of such choice options is deleted, the column is attached to another choice option with the same value. If no choice option with the column's value remains in the system, the column is deleted during the synchronization. The synchronization of columns happens every time a board form is opened.
The columns for the Backlog, Development, Review, Testing, and Done states are created active. The columns for other states, including the custom ones, need to be activated manually if necessary.
When columns are added for a new board, the system sets up their Order according to the Order sequence of the choice options for which they are created. The order of each column is calculated as The order of the previous column + 100. The order of each new column added to the board after the initial column creation is calculated as The highest order among existing columns + 100.
Read more in the documentation.
Update of project creation and completion
We have updated the interface and functionality of one of the project creation stages. Now, when you select the task types to be added to the project, you need to specify a State model for each of the selected task types. After the creation of the project, the State Models in Project (pda_state_model_project) records are created automatically.
The Deactivate option is no longer available for incomplete tasks when a project is completed. Now, you can only Cancel them and Move to a different project. The criteria of incomplete tasks when the project is completed have also been updated: the incomplete tasks belong to a task type of the first, second, or third level; they are neither released nor canceled; and they are not in the final board state. If you reactivate a project, the canceled tasks will not be reopened automatically.
Read more:
Update of task boads, preview widget, and task creation from related lists
-
The transitions available to tasks on boards are now determined by State Models in Project (pda_state_model_project). If a task type's state model in project cannot be defined, any state transition is allowed. The Released and Canceled tasks are not displayed on the board.
-
We have updated the complete and incomplete tasks criteria in the Complete the sprint modal window:
- The complete tasks are uncanceled tasks in the final board state or a state after the board, or uncanceled tasks in any state with the Released marker.
- Incomplete tasks are uncanceled tasks of the first, second, and third levels that do not meet any of the criteria listed above.
-
The info box of the Complete the sprint modal window now becomes green if all the sprint tasks are completed. We have also fixed the calculation of the sprint End date when the Create a new sprint option is selected.
-
When a task is added from a board, a modal window now opens, where only the third-level task types added to the project are available. The available options include states before the board and the board states.
-
The task cancellation modal window opened from the preview has been improved. The Cancellation reason field is now mandatory. The visual aspect of the preview widget has also been improved: the task state is now displayed as a label, the color of which is defined by the state column style rules.
-
The access control rules of the Create task button on the Product (pda_product) form have been updated: the action is now available only to users with the pda_admin, pda_user, or admin roles. Similar button has been added to the Project (pda_project) form.
Read more:
Update of the Add tasks to board and Sprint planning widgets
We have refactored the Add tasks to board and Sprint planning widgets for the Kanban and Scrum projects correspondingly. The update was required to use the new functionaltiy in the widgets and improve their user experience.
In both widgets we have replaced the hierarchical task list with a new list created with the recordList Simple tag. Records are grouped by their Parent task in this list. The new list supports inline editing – a tool that allows you to edit tasks without opening their forms.
The Create task button in the widgets now opens a new task creation modal window. The state before the board and the first board state are available in this modal window.
Add tasks to board widget
- The widget has been renamed from Add tasks to backlog to Add tasks to board to take into account the possible use of custom state models.
- We have changed the conditions of the task list filters in the add task to board widget.
- The WIP limit counter is now displayed only if all selected tasks are added to the same column. Warning messages now let users know whether the WIP limit has been already exceeded or will be exceeded if they add the selected tasks to the board.
- We have updated the title of the Add tasks to board modal window: it used to be called Add tasks to backlog.
- When tasks are added to the board, their current state changes to the first board state, if such a transition is possible according to the task type's state model in project. If there is no state model in the project for a task type, the Order of the current state choice option must be lower than the order of the first board state for a task to be added to the board.
Sprint planning widget
- We have changed the conditions of the task list filters in the sprint planning widget.
- The list of sprint tasks is now built with the recordList Simple tag. It shows uncanceled tasks of the third-level types connected to the sprint.
- The sprint launch action becomes inactive instead of being hidden if the sprint has no tasks or there already is an active sprint.
- When a sprint is launched, the tasks that are in a state that has a transition into the first board state are added to the board, as well as the tasks in the board states. If the sprint has tasks for which such a transition is not possible, a warning message is shown in the modal window.
Read more:
Configuration of burnt state in the chart and release update
A new UI action called Configure report has been added to the Sprint Burndown Chart. When clicked, it opens a modal window where you can select the burnt state for each task type added to the sprint. The story points of tasks in this state and the states following it are considered burnt. Canceled tasks are not considered for the calculation of story points and are not displayed on the chart.
We have updated the criteria of complete and incomplete tasks when a release is published:
- Complete tasks are the tasks of the first, second, and third levels that are in the state with the highest value specified in the Order field.
- Incomplete tasks are the tasks of the first, second, and third levels that are not in the state with the highest value specified in the Order field.
The SDLC Tasks related list has been added to the Product Module (pda_product_module) form.
Read more:
Update of task forms logic
-
The Product, Release, Product module fields are now displayed on the form regardless of whether the Product development checkbox is selected on the form of the specified Product, and they are no longer cleared when the value of this checkbox changes or when another project is specified.
-
You can now specify only an active Project that has the current task type added on the task form.
-
If the specified Project has the Product development checkbox selected:
- in the Product field, you can only specify a record related to this project. If the project is not related to product development or not specified, you can specify any product that is not in the Archive state,
- the Product field becomes mandatory,
- when the Product field is cleared, the Project field is automatically cleared as well.
-
The Rank, Assigned to, Project, Product module, Release, and Sprint fields are no longer mandatory. The Sprint field is displayed on the forms of tasks related to Scrum projects regardless of the task state.
-
The taks display name is now generated according to a new template: Task number [Project code] Task subject. The template slightly differs for the new Test Case and Automated Test task types: Task number [Project code] External number Task subject.
Read more in the documentation.
Improvements
New task types
New third-level task types have been added to the SDLC application. For each of the task types, we have added a table inherited from the SDLC Task (pda_backlog_item) table, and created new fields, unique state models, and state column style rules.
| Task type | Task type table | New fields |
|---|---|---|
| Design story | pda_design_story |
|
| UX research | pda_ux_research |
|
| Test case | pda_test_case |
|
| Automated test | pda_automated_test |
|
| Documentation task | pda_documentation_task |
|
Some of the fields on the design stories and UX researches forms are located on a new tab called Results. A new Publications tab has also been added for the documentation tasks.
New task types allow the system to reflect the actual progress and ensure a clearer interaction between the development, testing, design, and technical writer teams. The unique fields and state models meet the needs of and address the differences between the functional directions.
The use of new task types will make task allocation, planning, and prioritizing easier and more transparent. Additionally, the new task types make the scaling of the project much easier, since a larger number of specific task types helps to keep the order in the development even on larger projects.
Read more:
New state model for Features
We have updated the Feature (pda_feature) task type state model:
| 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. |
The new state model supports more peculiarities of the feature development.
Read more in the documentation.
Update in the logic of processing of an incident related to a defect
We have updated the reference qualifier of the Related defects field on the Incident (itsm_incident) form to make active uncanceled and unreleased records available for selection by default. When a defect related to an incident gets the Released marker, a message is added into the incident's Activity Feed. A record about the start of the work on the defect is no longer added.
Read more in the documentation.