A sprint is a dedicated period in which a set amount of tasks will be completed on a project.
Although sprints are traditionally associated with the agile methodology, specifically Scrum, ITM Platform supports sprints in Waterfall (Gantt) and Agile projects.
Go to the “General” tab, under the “Timeline” section, and tick the “Enable Sprints” checkbox
You can also enable sprints by default in a given project type. Go to CONFIGURATION > PARAMETERS > Project Parameters > Project Type, select the project type you need to customize and tick the “Enable sprints by default” checkbox.
Once sprints are active and populated with tasks, you will only be able to disable the sprint feature if all sprints are emptied first.
Once the sprint feature is enabled, you will notice a new “Sprints” tab and the presence of sprints across other features, such as the task list, the Board, or the Gantt chart.
The sprints tab
The sprint section offers a view of all sprints, allowing you to create and edit sprints and allocate tasks or send tasks to the backlog.
Sprint dates are flexible: you can set no dates, just a start date or both start and end dates.
The filter section will allow you to hide sprints whose tasks are all completed (in a completed status)
The task list
The tasks section has a “Sprint” field in the column selector, as well as a filter to display tasks allocated to one or more sprints.
From the task list, you can allocate multiple tasks to a sprint by selecting them, then clicking on the Sprint dropdown button and selecting the sprint that you want to allocate the tasks to.
You can allocate tasks already in a different sprint or in the backlog.
You cannot allocate archived tasks. You will need to move them out of the archive, then allocate them to a sprint.
Similarly, you can move multiple tasks to the backlog or the archive following the same procedure but clicking on the “Update Status” button.
Tasks moved to the backlog or archive will be deallocated if previously allocated to a different sprint.
You can also create a sprint from the tasks section by clicking on the “Add New” button.
Clicking on a task will lead you to the task “General” section, from which you can also allocate or deallocate it from a sprint.
Agile projects
When the sprints feature is not enabled, an agile project will behave like a Kanban project: one single board containing all tasks in an operational status (all but backlog and archive).
When sprints are enabled, tasks can be allocated to sprints and the Board will display the tasks allocated to it
A typical workflow would imply assigning tasks to a “to-do” status, then as the team makes progress, tasks will flow to an “in-progress” status, then to a “completed” status.
From the Board, you can navigate sprints using the dropdown or the arrows.
Similarly, the project report section has the ability to filter all reports (tasks percentages, cumulative flow, burndown) by sprints, or the whole project
Progress reports will adapt to the sprint you have chosen.
Waterfall projects
Predictive projects can also take advantage of sprints, using the common features, plus filtering or sorting on the Gantt chart by sprint.
Reports, extensions, and API
Sprints are an entity in ITM Platform, just like projects or tasks. Therefore, you can create custom reports, extensions that react to changes or use the API to read, create, and manipulate sprints.</h3
In the “Progress” section of an Agile methodology project, you will find the following sections: Progress Report, Tasks by Type, and Charts / Diagrams.
Progress Report
The manual progress report makes it possible for the project manager to create a record that indicates the progress observed (% completed), as well as the evaluation (list of configurable values), a description, and a date.
This is useful when the progress of the project is not only represented by the consumption of tasks, but by the achievement of the deliverables of the project.
Task progress report by changing the task column
When you move a task to a completed column, you can configure the system so that its progress is increased to 100%, generating automatic progress report.
To configure this behavior in agile projects, access “Edit board layout”, edit the column of the type “Completed” that you want and tick the checkbox “Automatically update to 100%”
Thereafter, the tasks you mark as completed will be assigned 100% progress.
Note that if you roll back the status to a “Pending” or “In Progress” type, you will need to manually assign the new progress, if desired.
Tasks by type
This chart represents the percentage of tasks in each status present in the project at this time.
The standard status types are “To Do”, “In Progress” and “Completed.” It is independent of the number of columns that the Agile board has because each column will be based on one of these three types.
Tasks per status can be seen in either the group or swimlane view.
You can also eliminate one of the statuses and in turn the chart will be recalculated based on 100 and display the remaining statuses.
In this example, we have removed the “Completed” status and now you see the composition of the backlog (Pending and In Progress).
Tracking Charts/Diagrams
This section provides two options: Burndown chart and Cumulative Flow diagram (CFD).
Both share the same filtering block which allows you to customize the displayed information according to your preferences.
Date Interval (start and end)
Determine the timeline the chart will represent.
It is important to note that the dates that are reflected in the charts are those of the task status changes. That is, they are not the start or end dates of tasks.
You can view all date and status changes in the “Event Log” section of the task.
Default settings
The Cumulative Flow diagram will start on the creation date of the first task and end today.
In the Burndown chart, the chart corresponds to the start and end dates of the project.
Dates representing verticals (X-axis) are the result of dividing the period by 14, so that regardless of the temporal dimension of the chart, you will always have a homogeneous view. If the duration is less than 14 days, you will notice as many intervals as there are days.
Columns and swimlanes
You can choose to show or hide tasks that belong to:
Columns: Remember that each column has one of three types and these are the ones that are represented in the charts.
Swimlanes: either used as process types or sprints.
Burndown Chart
Represents the dynamics of tasks completed.
The Burndown chart is generally used when all tasks are determined from the beginning.
Let’s look at an example:
Notice that the backlog shows tasks that are created on the same day. Let’s see what happens if we move one to “Completed” status and another to “In Progress”.
If we follow the completion rate of tasks, we will eventually leave the work column pending to zero.
However, if we add “To Do” tasks as the project or sprint continues, we will notice anomalies in the trend because instead of reducing the backlog, it will increase.
Expected line of progress
This is a straight line that connects the number of tasks in the “To Do” status on the Y-axis to the beginning of the interval on the X-axis at that point in time. At that point in time, there should be no pending (Y-axis =0), so it is steadily declining.
How to interpret: If the tasks are of similar size, the number of pending tasks should be represented by the expected progress line.
Actual line of progress
Represents the actual number of pending tasks on interval. That is, the overall pending tasks at the start minus those completed. We’ve explained this concept prior with bar chart example.
The slope of the progress line indicates the “velocity” and determines the number of tasks completed per time block (usually a sprint).
How to interpret a Burndown chart
On-track: The expected and actual line of progress are together. If it keeps this pace, the project will end in time.
Behind schedule: If the actual progress line is above the expected line, it means that the team is delayed and should have completed more work at this point.
Ahead of schedule: If the actual line of progress is below expected, it is progressing at a faster pace than expected. You can finish earlier than expected or add tasks. These interpretations are valid as long as the tasks are the same size, i.e. the time to solve them is similar.
Burndown Diagram Limitations
The Burndown diagram only represents the completed work. It reports the pending work, but it doesn’t reflect what is in progress.
Burndown works best on sprints or short projects and makes less sense with long-term projects. In long-term projects, pending work goes through many changes in order for the estimates to make any sense. This is the biggest reason why Burndown is not recommended for Agile methodology.
The Burndown diagram represents scope changes, as changes in the backlog are not displayed effectively. These limitations are overcome by the Cumulative Flow Diagram.
Cumulative Flow Diagram (CFD)
A Cumulative Flow diagram is a stacked area chart that shows, in each time interval, the number of tasks per status.
Reading the CFD
As you go along, the diagram shows the task flow by status. It is called “cumulative “because it does not measure increments between intervals but counts each element in each status, regardless of whether it was in that same status previously.
This way, it solves the main Burndown problem, as it represents situations in which to-dos are not all created on the first day.
The CFD provides two fundamental pieces of information in Agile management: Work in Progress (WIP) and Cycle Time (CT).
The “In Progress” bandwidth represents work in progress (WIP).
The space between time intervals provides Cycle Time (CT) represents the average time it takes a task to move from one status to another.
Limitations of the Accumulated Flow diagram
Despite solving the main limitations of the Burndown chart, the CFD has its own limitations.
• It does not reflect whether any task is blocked
• Related to the previous one, it does not indicate the individual cycle time, which means the amount of time that a particular task has remained in a single stage.
These limitations can be resolved through reports or custom views of tasks.
A swim lane (or swimlane diagram) is a visual element used in process flow diagrams, or flowcharts, that visually distinguishes job sharing and responsibilities for sub-processes of a business process.
The swim lane flowchart differs from other flowcharts in that processes and decisions are grouped visually by placing them in lanes. Parallel lines divide the chart into lanes, with one lane for each person, group, or subprocess. Lanes are labeled to show how the chart is organized.
In this example, you have a swimlane for Issues, another for Error correction, and another for New features.
