In 2021, we noticed a trend with several of our full-stack development squads (scrum teams) of a stagnant or decreasing sprint velocity. My colleague Scrum Master Lauren Williams and I theorized that the cause of this was consistent over-commitment by the squads during sprint planning.
This over-commitment was understandable given the aggressive roadmap that our organization had for the year and the high level of dedication from our squads. However, it was clearly having an impact on the teams’ ability to deliver consistently and at a high volume.
A commitment experiment
We decided that we’d start an under-commitment experiment with one squad as a proof of concept (POC) to see its impact on velocity. In the next sprint planning session for Lauren’s squad, she told them that they would commit less than during previous sprints. She shared with the squad the Velocity Reports in Jira to show the pattern of high levels of commitment and stagnating or decreasing velocity.
It was a tough sell. The team, including the product owner, had a desire to commit to more work upfront. However, Lauren reassured them that the work was prioritized in the backlog and in future sprints, so as developers had capacity, they could pull from the next sprint’s prioritized tickets in Jira. The team agreed and the experiment started.
During the sprint, as developers completed work (pull requests were approved and changes were in a test environment for verification), they picked up new work from the prioritized list in the next planned sprint. They would announce that they did this in the team’s Slack channel, link the ticket in their message, and self-assign the ticket. Lauren would confirm that the sprint field was correct for the current active sprint and any relevant labels used for tracking were added. (These tickets were not considered sprint interruptions.) If a developer was unsure about which ticket to pick up next, based on their level of experience or overall skill set, they would create a Slack thread to get advice and direction from the squad’s lead developer.
Results
This process went smoothly, and at the end of the sprint, the team had increased their velocity from the previous one and had a lower level of initial commitment. The QE (testing) team members found the flow of work manageable as well, and the product owner was satisfied by the quality and quantity of work that was completed.
The biggest win, however, was the feeling of satisfaction that the team experienced. They felt motivated and “hungry” for work throughout the sprint, and there was even some lighthearted competition among some team members. The team also appreciated the results. They felt proud about their increased velocity and how it didn’t negatively impact the flow of their work or the quality.
A new way of working
The next step was to see if this approach would have the same result in the next sprint. Lauren and the team followed the same process and achieved a successful sprint with improved velocity.
Finally, this was shared with the other back-end, front-end, and full-stack squads in our organization. The ones who followed the practice of under-commitment achieved an improvement in their sprint velocity.
Based on our experiences, we recommend that a practice of under-commitment creates a motivated team that has the time and mental space to stretch within the sprint and achieve higher levels of task completion.
Give it a try and let us know how it goes for your Scrum teams.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
