Saturday, January 18, 2014

Ideal Agile Scrum Sprint Length

Never "hard code" any sprint length:

Agile-Scrum is a popular combination of project management methodology; to practice it with confidence, it is important for mastering project management techniques and the mechanical levels of Agile. To some extend that is also why experience is so valuable in project management. Here is collective sharing upon Agile Scrum Sprint Length.  

  • As short as you can, but no shorter. Well communicate the Sprint goal with all your stakeholders prior to the sprint commencing. As long as everyone is aware of what you have to achieve then the timeframe can be decided upon. Obviously it is important to build a "rhythm" for the team as much as possible but this should become obvious as you progress. Things to consider:
    -Are you able to complete entire stories within a Sprint?
    -Are you delivering value in a Sprint?
    -Is the PO happy with the time frame for priority changes? 
  • Never "hard code" any sprint length: The biggest factor is how expensive it is in terms of team effort to "complete" the sprint. For instance, if the team's definition of done includes tested software deployed to production, the amount of time it takes to perform the testing and deploy the release into production is going to be a critical factor. If you are unable to finish entire stories within a sprint, perhaps the stories are too big. Shortening the sprint forced smaller stories and allowed completion within the sprint. Seems counter-intuitive, but it worked. If the Product Owner feels that they aren't getting to re-prioritize often enough then it's too long. 
  • It depends on team and project size, it also depends upon the nature of project, two week sprint is more suitable most of the time. In true agile spirit, that during the early stages of a project do three week sprints to cater for investigative tasks which will impact development and testing further down the line. Then tune back to two weeks once your project is gathering momentum. It more often than not 2 weeks is the best interval for a medium sized team (5-10 team members) as longer tends in introduce more chance for unexpected events which can disrupt the sprint. In addition it provides a more regular feedback from clients. The exception to this is when running a team with larger user stories which are well defined but for what ever reason can not be sliced into smaller chunks. In such case a longer sprint makes sense as it takes more than 2 weeks to deliver.
Hence, the Spring length needs to be elastic to well reflect the Agile principle for continuous improvement and collaborative interaction


I have done scrum for 2 and a half years at my previous company, and following an agile process at my new company for 7 weeks. Our first ever trial sprint at my old company was one week, and every one after that has been a 2 week sprint which always ended like clockwork regardless of whether how many stories were remaining on the board. Except for one time when we called an "abnormal termination" of the sprint halfway through.

In my new company we aim for 2 week sprints but this last one has been continually extended as developers have said they are not ready to start a new sprint. To me this seems totally anti-scrum and a poor practice.

However this article seems to be advocating this approach. Are you saying that a new sprint should only begin when the developers want to start a new sprint? Or when all of the stories in the current sprint have been completed?

Post a Comment