Skip to content

Iteration Cadence Feedback

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

This issue is aimed at collecting feedback and discussion around the recently shipped Iteration Cadences (https://docs.gitlab.com/ee/user/group/iterations/#iteration-cadences) feature within GitLab. Please see "Discoto Usage" for how to create new discussion topics and automatically keep their status up to date within the issue description.

Why did you deprecate manual iteration scheduling?

TL;DR:

  • Manual iteration lengths introduce variability into velocity and volatility calculations.
  • This variability results in a negative impact on a team's ability to set accurate commitments and expectations.
  • We've removed the ability to manually schedule iterations to help teams reduce volatility from iteration to iteration. Tracking velocity and volatility within GitLab is on our upcoming roadmap.
View full response

No matter what Agile methodology you practice, we've designed Iterations (or Sprints if you're doing Scrum) around the following philosophy:

We stop at predetermined, unchangeable time intervals and compare reality to plan.

Iterations are the heartbeat of a...project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they've pumped out working, tested software for each story and are ready to begin the cycle again.

Iterations are an important safety mechanism. Every [insert your iteration duration here], the team stops, looks at what it's accomplished, and shares those accomplishments with stakeholders. By doing so, the team coordinates its activities and communicates its progress to the rest of the organization. Most importantly, iterations counter a common risk in software projects: the tendency for work to take longer than expected. Reference

One really important aspect of iterations is scheduling work that you feel confident in committing to being able to complete within the scheduled iteration timebox. One of the most helpful (and accurate) ways to do this is by understanding your team's historical velocity and volatility. We removed the ability to manually schedule iterations because of the negative long-term impact it has on the accuracy and reliability of using velocity -- which we plan to implement natively within GitLab -- to make committments. When iterations can be scheduled manually, you will often end up in a scenario where you have many iterations that do not have the same duration. This increases the volatility of your velocity, thus decreasing your confidence levels in making commitments. This negative impact is illustrated below:

Iteration Working Days Weight Completed Velocity Standard Deviation Volatility
1 10 20 20.0
2 15 30 25.0
3 10 18 22.7
4 10 21 22.3
5 15 35 26.0 7.3 28.18%

In the above example, after only five iterations, there is a 28.18% volatility, which more or less means that given the velocity of 26, for my next iteration, my team is likely to ship somewhere between 19-33 weight. This is a huge disparity and greatly increases the ability to make sound commitments and/or surface important trade-off discussions with stakeholders.

By having iterations with the same duration, we can immediately reduce volatility as illustrated below:

Iteration Working Days Weight Completed Velocity Standard Deviation Volatility
1 10 20 20.0
2 10 21 20.5
3 10 18 19.7
4 10 21 20.0
5 10 17 19.3 1.8 9.44%

The volatility has decreased to 9.44% and given a velocity of 19.3, my team can expect to deliver somewhere between 17 - 21 weight. The lower volatility makes managing risk much easier.

Can I still use manual scheduling?

Yes, until we remove the feature in a later version of GitLab. To add a new iteration to a manual cadence, click on the three dot icon to the far right of the cadence title to show the option to manually add a new iteration.

Auto-Summary 🤖

Discoto Usage

Points

Discussion points are declared by headings, list items, and single lines that start with the text (case-insensitive) point:. For example, the following are all valid points:

  • #### POINT: This is a point
  • * point: This is a point
  • + Point: This is a point
  • - pOINT: This is a point
  • point: This is a **point**

Note that any markdown used in the point text will also be propagated into the topic summaries.

Topics

Topics can be stand-alone and contained within an issuable (epic, issue, MR), or can be inline.

Inline topics are defined by creating a new thread (discussion) where the first line of the first comment is a heading that starts with (case-insensitive) topic:. For example, the following are all valid topics:

  • # Topic: Inline discussion topic 1
  • ## TOPIC: **{+A Green, bolded topic+}**
  • ### tOpIc: Another topic

Quick Actions

Action Description
/discuss sub-topic TITLE Create an issue for a sub-topic. Does not work in epics
/discuss link ISSUABLE-LINK Link an issuable as a child of this discussion

Last updated by this job

Discoto Settings 
---
summary:
  max_items: -1
  sort_by: created
  sort_direction: ascending

See the settings schema for details.

Edited by 🤖 GitLab Bot 🤖