We’ve been experimenting with one week sprints on two current projects. So far the results have been less then stellar. The teams themselves decided on the one week sprints. In one case they just argued strongly that they could add value within a week and then get rapid feedback from an internal customer. In the other there was only 3 weeks left to complete coding on a product, so it was broken into 3 week long sprints.
So far a few observations:
- It’s very difficult to get a regular rhythm in a single week.
- A few absences or company events can really take the wind out of a week long sprint. On a two person project one of the developers was out 3 of the 5 days of the Sprint. So we pushed quite a few user stories over into the next Sprint.
- The overhead is higher with more demonstrations and sprint planning meetings. There also isn’t a lot to show to the customer that’s new.
- One week sprints have a tendency to degrade into 1.5 or two week long sprints anyway. This happened on one project because as things slipped the sprint just got extended. This was really more of an issue with holding firm on time boxing, but it was related to attempting the one week sprints in the first place.
- You really need to break down user stories or features into small tasks, preferably mostly 2-4 hour level tasks. On the project where we didn’t really break things down we realized the team had taken on far too much.
The outcome of these experiments is that I’ll argue strongly with my tech leads if they want to try one week sprints again.