Team capacity – iceScrum

Documentation This documentation applies only to iceScrum v7.
For old iceScrum R6, read the documentation or migrate.

Contents


For each sprint, team members enter their availabilities / time spent on the project on a daily basis.

Configuration

First, you need to enable the “Team capacity” App in your project.

Then, it also requires to be configured in your project settings before your can use it. Once it is configured, enable availabilities management. Then, availabilities with the chosen default value will be automatically created for your sprints (“in progress” and planned ones).

You can change the default availabilities at any time, but it will only affect new availabilities.

If you disable activity management, availabilities for planned sprints will be deleted. Availabilities for “in progress” and closed sprints are kept so you will get them back when re-enabling availabilities management.

Availabilities display

Availabilities table

Once the App is enabled and availabilities are configured, the table is available from the sprint plan toolbar. Everybody having access to the sprint plan can see it.

The table displays total availabilities by day, by user and for the entire sprint. Current day availabilities have bold font and weekend availabilities have grey background.

Project availabilities charts

At the project level, it is useful to compare availabilities between sprints. A chart that displays the total availabilities per sprint is available from the project dashboard.

Availabilities and remaining time

If your use the same unit (e.g. hours) for remaining time and availabilities then it is interesting to compare their values. In addition to this section, you can also read our blog post about availabilities: https://www.icescrum.com/blog/team-availabilities-why-and-how/.

Sprint burndown chart

The traditional sprint burndown chart compares the remaining time to an ideal download line that starts from the remaining time at sprint activation and decreases linearly to 0. However, if you use availabilities then there is a much better curve to compare your remaining time with: the remaining availabilities!

In an “in progress” and “todo” sprints, you will find a new chart named “Sprint burndown (Availability)” that replaces the ideal line by remaining availabilities. Past availabilities values are recorded while the ones for the current and upcoming days are dynamically computed from the current availabilities taken from the availability table.

Be careful, you want the curves to have the same trend but you don’t want them to be superposed! Indeed, the remaining availabilities must be above the remaining time to take into account risks and additional time needed to manage emergencies. Read the next section about “sprint slack”.

Sprint slack

The slack S that represents the room your team has between the expected work and the maximum work that can be done is calculated from the sprint total availabilities A and the sprint total remaining time R like so:
S = A – R

It is displayed in the sprint plan (for “in progress” and “todo” sprints). You can disable slack display in your settings under the “team availabilities” section (e.g. if you don’t use the same unit for remaining time and availabilities).

For an “in progress” sprint, the slack is calculated from the remaining availabilities (the sum of the availabilities from the current day included to the end of the sprint) so they can be compared to the current remaining time.

It is good to ensure that your sprints have enough slack. Indeed, it allows working on unexpected tasks, absorbing underestimations or giving your team time to improve their work.

The slack rate slackRate is calculated from the slack S and the remaining time of the sprint R like so:
slackRate = S / R * 100

The slack color is computed after the slack rate, helping you to determine if there is enough slack. Here is the default color scheme:

  • slackRate > 40%: blue
  • 30% < slackRate < 40%: green
  • 20% < slackRate < 30%: orange
  • slackRate < 20%: red

A project may be risky and require a lot of slack while a project with a well known context may require a little slack. You can adapt the color scheme according to this context by changing the thresholds in your project settings, under the “team availabilities” section.

Edition

Permissions

Team members can edit their own availabilities until the sprint is closed. Scrum Masters and Product Owners can edit the availabilities of all users, regardless of the sprint state.

Accepted values

You can expand a cell of the availability table to copy its value to adjacent cells as you usually do in spreadsheets. You can also copy/paste availabilities from spreadsheets.

You can enter any integer or decimal value (using “,” or “.” as decimal separator). The only restriction is that values must be positive or zero.

Weekends

By default, weekends have empty availability (zero). Moreover, if you have selected the “Hide weekends” preference in your project then weekend availabilities are read-only in the table.

Team updates

Add a team member

When you add a team member, corresponding availabilities with default value are created for planned sprints. Empty availabilities (zero) are also created for the “in progress” sprint.

Remove a team member

When you remove a team member, availabilities for planned sprints are deleted. Availabilities for “in progress” and closed sprint are kept.

Sprint updates

Create a sprint

If availability management is enabled, creating a sprint will automatically create its availabilities with default value.

Activate a sprint

When you activate a sprint, the total expected availability for the sprint is saved. It is displayed in the availabilities table and compared to the “actual availabilities”. “Expected availability” by user are also available through the Web Services API.

Update sprint dates

When you update your sprint dates:

  • If you add days to the sprint, corresponding availabilities with default value will be created.
  • If you remove days from the sprint, corresponding availabilities will be deleted.

Please note that shifting a sprint (e.g. delaying the beginning of the sprint but keeping its duration) will both create days and delete availabilities (here head availabilities are deleted and tail availabilities are created).

Delete a sprint

If you delete a sprint, all its availabilities are deleted.

REST API

Availabilities can be queried and updated through the iceScrum REST API, e.g. to feed an external tool.

Previous << Cloud attachments
Next Bug trackers >>

Try it for free now
All you need for your Agile project management