We decided on this length as, when we started development, the requirements for this project were in a state of flux and we felt that a shorter 1 week sprint would give us the most flexibility to deliver the changing priorities.
As the Product Owner continued to drastically change their priorities it became clear that the shorter sprint did allow us the flexibility we needed to continue to provide value to this particular client. However there were a number of challenges that this created. During a 1 week sprint our team found it hard to find a rhythm to their week, it was almost as if they were always trying to catch up in order to deliver their committed requirements. This lack of rhythm was visible in the sprint burndown which didn't seem to find a flow, meaning that we couldn't use it to predict if we were on track to deliver or not.
Also, there was a lot more overhead with twice as many planning and review meetings than we normally had, meaning that there was less time for delivering requirements.
These byproducts caused our team to tire quickly and we wouldn't have been able to keep up this pace for longer than 5 or 6 weeks.
Our team found that shorter sprints are possible, and sometime necessary, however the pace can be difficult to maintain for more than a few weeks.
No comments:
Post a Comment