Allowing time for testing
Update: Ed Gibbs writes (here) about some of the challenges that he’s facing within his organization. Interesting stuff.
I like two week iterations. The short timeframe ensures quick feedback, and makes the team more responsive to the Product Owners needs. But two week iterations can be very uncomfortable for teams that are familiar with delivery cycles that span months. One of the very first issues that is raised is that the team does not have sufficient time to be “done”.
Typically what this means is that the software will be code complete at the end of an iteration, but will not have been fully tested. It usually gets delivered late and hence there is insufficient time for full and rigorous testing. After the third of forth sprint it’s common for a team to ask me if we can change to three (or four) week iterations to “allow more time for testing.“
I’ve recently had the opportunity to simultaneous watch three different project teams each with a different length Sprint. All of these projects are part of the same organization, so they all have the same “done” criteria, similar technologies and tools, and a similar set of organizational impediments. Each of the different teams behaved very differently, however. Each of the teams is briefly outlined below.
Done for this team meant fully functional code with unit tests, tested by another team member, completed documentation and a demo for the Product Owner. That’s lot of work to achieve within a short period of time, but team Piglet were very efficient and were defining their test scenarios within a day or two of starting a new Sprint.
Team Pooh: Team Pooh were a medium sized team of 10 people, working 3 week iterations. Althought there were one of two individuals on the team that had previous Scrum experience, it was a very new team and it took several iterations for the team to settle into a comfortable rhythm. They teams initial iterations were marked by many incompleted Stories.
A comment that was frequently heard during the early retrospectives was that code was delivered late to the testers; usually just a day or two before the end of the iteration. As the team became more practiced, they deliberately tried to deliver working code earlier and earlier to the testers.
Team Tigger: The final team that I observered was a medium sized team of 7 people, working 4 week iterations. This team had the most difficult time of all the three teams. The team members were bright, motivated and were truely doing their best, but had difficulty delivering fully functional and tested software. Perhaps the most significant factor that caused this team to stuggle was that their stories were major epics and needed some serious decomposition. I personally feel that this team is typical of software teams trying to migrate to Scrum. All teams need to go through their periods of pain before they inspect and adapt.
Conclusions
I have a preference for two week sprints. But by the same token, I have no object to two three or four week sprints. If a project team wish to increase the length of their sprint, that’s fine with me provided it’s for the right reasons.
Increasing the sprint length to “allow more time for testing” does not address the teams root problem. If a team cannot be “done” in two week iterations then it will not be done in three week iterations. Far better to stay with two week iterations and learn how to deliver software that’s “done”. Only once the team have mastered this should they be allowed to increase the duration of each sprint from two weeks to three or four weeks.
We’ve been considering a 3 + 1 schema for one iteration. 3 weeks of development with full focus on stories and tasks and one week of stabilizing, with intensive testing (by team members and QA testers) and fixing. This way we can keep the monthly rhythm and should be able to reach a higher quality level. The team which develops the Eclipse IDE is obviously working like that. What do you think of this?