I’ve just seen this post on Chip’s blog. He questions whether 30 days for a Sprint (which is what the Scrum process recommends) is perhaps too long, I’ve always thought so myself and in fact, if I remember rightly, Mike Cohn suggested 2 week Sprints on the Scrum Master Certification course that I attended.
When I ran the project before Christmas I used 1 week sprints, I deemed them to be appropriate as it was for 8 weeks and so I wanted to establish a rhythm within the team very quickly as well as provide feedback to the client as soon as possible. This placed the team under an immense amount of pressure and as Chip rightly says almost promotes a feeling of chaos.
What is also interesting is that we have a couple of teams that are permanently involved in a programme of project work relating on two of our biggest applications. Whilst those teams are primarily focussed on the development of new features they also have to handle the support calls that we receive that pertain to those systems.
The two teams in question have recently decided to implement Scrum, however, rather than the 30 day Sprints that the traditionalists suggest they are using 10 days. As I understand it, they have approached the problem differently with one team opting to roll the support calls in to their Product Backlog and the other having established a separate team that handles the issues.
I’ve also given consideration previously to how an Agile approach might work in one of our SAP development teams. About 6 months ago a live issues team was created to work through the backlog of bugs raised by the business. I think the Scrum model could be extended to manage the release of fixes and ]the business priorities within those. This is of course, always a little more difficult when there are multiple business owners, one method that I have been made aware of for dealing with this though is to allow a different member of the business to adopt the Product Owner role on a rotational basis for each of the Sprints.
For me though, I think 2 weeks feels about right for the length of an iteration. It doesn’t put the team under an undue amount of pressure nor does it extend the feedback loop by too much.