Monitoring Issues vs. Making Changes

Although short development cycles give the team more frequent opportunities to make changes to their processes, you want to be careful to make reasoned choices and not just make a change for change’s sake. Issues with team dynamics should be addressed as they occur but issues such as a one-sprint dip in the team’s velocity might not merit immediate concern.

Perhaps the drop in velocity was due to unexpected delays due to issues with the software testing environment managed by an outside team. Although such a cause might be a reason for your team to ensure that backup testing equipment is available, it would not necessarily be a reason to change the way in which stories are sized or change the length of the team’s sprint to give the more time to finish tasks.

When deciding on whether to implement changes, you should also consider the maturity of your team. Is your team new to Scrum and not experienced with sizing work for short development cycles? Do you have new team members who take longer to perform tasks, as they are unfamiliar with the technology used by your team? If you answer is yes to either of these questions, you might want to consider ways that you can get everyone comfortable working in an Agile environment and/or with new technology.

Sometimes issues can be resolved by spending a little time with the team or individuals to provide some coaching or mentoring. For new scrum teams, consider reviewing the details of a baseline story before beginning to discuss new stories during backlog grooming. For new team members, consider giving them an overview your team’s software architecture or providing a demo of recently completed stories that relates to work to be done in an upcoming sprint.

You can make bigger changes, like changing the length of your sprint, but those changes should not be considered lightly. Work should be sized to fit into the sprint. Sprints should not be sized to fit the work. The length of the sprint should be set at the beginning of the sprint and should be consistent from sprint to sprint. You should not change the length of sprints because you anticipate that your team will not be able to complete all of their user stories, and you should not change the length of your standard sprint because you planned more work in the current sprint than you did your last sprint. Changing sprint length interrupts the cadence of work that a team achieves after working with a set sprint length.

That said, some teams find it better to work in two-week sprints and some find it better to work in three-week sprints. Your team might benefit from changing the length of its sprints to optimize their efficiency.

Before making any changes to your team, consider whether there is enough evidence support that the changes will be beneficial and how long you will monitor the changes to determine whether they have had the desired affect. The Agile principles dictate that “… the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” However, impacts to the team and their ability to produce working software should be part of the team’s reflection and decision to make changes.