In my first Scrum project we started with 3 week sprint cycle. We opted for this sprint length to be different from what others were doing. As we progressed, we had numerous debates about whether we should bring the length down to 2 weeks or move it up to 4 weeks. Finally, we decided to try and learn. We ended up choosing 4 week sprints as the team felt that we are not Agile enough for shorter sprints. We needed to take concrete actions to improve our agility. Rest of the article summarizes various learning from this experimentation.
RULE OF THUMB: Generally speaking, teams should inspect and adapt. There is no ideal length of a sprint, however can be:
- Inversely proportional to the agility of your team
- Inversely proportional to the frequency of the changes
-
Directly proportional to the technical complexity of the project
Let's focus on Agility as other two factors are easier for you to quantify.
If your team is very
Agile
then shorter sprints are better, however, if your team is less
Agile
then larger sprints are better. Bottomline is that whatever sprint length you choose, stick with it for the entire release.
How do you identify level of agility? Here is a list of key parameters, which will help you gauge your team's agility:
- Agility of your engineering practices: Can you build, deploy, and test (automatic) with every code check-in? [high agility] v/s [low agility] Do you give a build to QA on a weekly basis to test?
- Quality of user stories: Are you able to write good user stories which can be executed in less than a week? [high agility] v/s [low agility] Your user stories can't be broken down to fit in a sprint and team needs multiple weeks to complete those as per the definition of "done" .
- Sprint Overheads: Sprint reviews are very light-weight. [high agility] v/s [low agility] Team needs to rehearse before giving demo to the stakeholders. Team is complaining that they hardly get time to code. In other words, you need to minimize sprint overheads to have shorter sprints.
- Cross-functional team: Every team member can work on most of the tasks, hence team always works on the highest priority tasks. [high agility] v/s [low agility] Team members have special skills, hence, tasks need to wait for those people to be available.
- Ability to rapidly change : Flexible architecture that allows to rapidly adjust with changing business realities with some refactoring. [high agility] v/s [low agility] Rigid architecture that may require complete rewrite to meet changing business needs.
- Technical debt : Low amount of waste [high agility] v/s [low agility] High amount of waste.
Finally, I just want to remind you that the length of a sprint becomes meaningless if your team is not correctly focusing focused on done. One of the most common reasons of Agile failure is not to have "shared" meaning of definition of done. Definition of done is a joint team commitment, which team agrees to deliver at user story, sprint, and release level. "Done" directly translates into "value" in Agile. If you need your product development process to deliver "value" then, you must give extra care to the definition of "done".
In a nutshell, it is good to adjust length of the sprints, however, it is a must to perfect definition of done for your team. Hopefully, you have perfected your definition of done already, hence, now is the good time to fine tune length of your sprints. Also, don't forget to check more Rules of Thumb here .
Reference
- Agile Rules of Thumb [ rules ]
- Rethinking Sprint Length [ article ]
- Synchronize rather than overlap sprints
- Definition of Done (DoD) - It's Too Critical To Ignore [ article ]
No comments:
Post a Comment