Scrum Principle : Sprint Duration of 30 Days. Sprints last 30 days. This is enough time for a development team to fully understand the contents of an increment, design it, develop it, and test it. If the team were given less time, the likelihood that they could develop a cohesive increment is lessened.
If a Sprint duration is more than 30 days, the likelihood of the Sprint’s incremental product is lessened. The environment into which it will be used is changing, the technology with which it is being built is changing, and management’s belief that the increment will ever be successful is lessening.
So keep the Sprint duration to 30 days, a reasonable balance between productivity and relevance.
Case Study 6
The first Sprint of a project was underway. The team had carefully selected their Sprint goal, balancing the relevance and power of the increment with what they believed they could deliver within 30 days.
As normal, a Scrum meeting was held on the tenth day of the Sprint. When it came to Tom’s turn to report, he indicated that he had been redirected by one of the senior managers to build something additional, something that built on the work already going on in the Sprint. And he had been unable to do the work that the rest of the team had expected of him, although he would try to catch up.
We immediately went to the senior manager’s office and asked what was up. He indicated that he had found an even better way for the team to win. He had been at an offsite and had learned that our sponsor was really hot to see some additional functionality. So he was giving us the inside scoop, pointing one of the team members to add this functionality to the Sprint.
The senior manager hadn’t been at all of the Scrum training, so we had to educate him on the importance of not interrupting a Sprint. That the team was protected during this interval from all of the chaos, complexity, and uncertainty during this interval.
The manager argued. He said that if he saw a $100 bill on the ground on the way to the train, he would bend over and pick it up. Why was this different?
We were able to get the team back on track. They successfully demonstrated their increment at the end of the Sprint. And the point that the senior manager had wanted to be demonstrated was no longer on the radar of our customer – it had apparently just been of interest that day at the offsite.
Lessons Learned :
In order to build a meaningful increment of product, a team needs to be protected from the environment surrounding it. The team meets prior to the Sprint and decides (with management and customers) what is the most meaningful thing to do over the next 30 days. The team then goes into a Sprint and does that work. The team becomes highly productive, and is freed from the constant start and restarting of work as the team and everyone around it guesses and second guesses the initiating decisions. Freeing a team from uncertainty and interference is probably the greatest productivity gain that occurs in Scrum. However, every 30 days, everyone gets to reevaluate the decision that led the team to build that increment. This reevaluation is based on changes that have occurred during the 30 days and the quality and functionality of the product increment build during the 30 days. Of course, the presence of the product increment biases the decision toward continuing to use it … if nothing is built, nothing could be built upon.The moment between Sprints where everything is reevaluated is called "punctuated equilibrium."