web analytics
Contact me 
Orange D inside a circle

One-week scrum sprint evaluation for prevent sprint backlog changes during sprint

2014-04-07 23:50

One-week scrum sprint evaluation for prevent sprint backlog changes during sprint

There are some cases where ideal or recommended practices are not what a team needs. Let me explain this a bit further. Imagine a scrum team that has worked for several months with two-weeks sprints. According to the literature and the opinion of many experienced authors, this sprint length is the ideal [1]. Now, what happens to this team if the client, for reasonable business causes, slow down the rhythm of story generation? What happens with this team if they find themselves without the number of stories needed to fill the next sprint? What if this team decided to start the next sprint anyway and, once the client start again to write down stories, add them to the current sprint backlog?

Although the sprint backlog change during the sprint should be resisted, the whole point of scrum is to allow you to adapt to the situation [2], so this was taken as an one-time solution. Anyway, the scrum master and the managers have to start to think about a more long-time solution if the situation repeats again in a following sprint. Now, one of the managers suggested that if the team makes the sprint shorter (one week sprint), then the new stories could being added to the next sprint and current sprint backlog will keep unchanged. Although this idea sounds promising, we decided to make a little research before making the decision.

About the sprint backlog change, we have found that others professionals have done the same questions as us and have reached to similar thoughts about this. The sprint backlog change (during the sprint) have to be exceptional, and should be taken as a learning moment for the team. As Andrej Ruckij said, this is a common problem for teams who are new to agile and it's ok to reduce the length of a the sprint [3]. About the one week sprint we have found the following pros and cons.

Pros:

  • Fast turnaround time. Worst case, a new idea has to wait just a week to start development and a week after that for the first product output. That first week will fly by just trying to flesh out the idea and confirm its prioritization. Most of the time you'll have scant days or hours to plan an idea before the next sprint starts.
  • Ideal for early-stage startups. The fast iteration is exactly what you need to turbocharge your learning cycle when looking for product-market fit.
  • The energy is high because the deadline is always this Friday. Every week is an end-of-sprint rush to the finish line and that is fun.
  • Scrum team members are less prone to fall into the procrastination trap.

Cons:

  • Hasty planning. You won't have time for several customer interviews with mockups and feedback before going to code. The feel of one-week sprints is a frenzied “near realtime".
  • What roadmap? When your horizon is a week don't even bother looking out a year. It's infinity away.
  • Story chunking. Every story should ship code by the end of the sprint. But it can be awkward to chop up large projects into chunks that are small enough to fit into a week.
  • one-week sprint still needs estimation, tasking, demo, etc. Relative to the size of the sprint those fixed time costs will now be high so they have to get rushed.

Also, we have found the following table which compares one to four weeks sprint lengths showing several challenges for each one [4].

Sprint length comparison

Challenges1 week2 weeks3 weeks4 weeks
In a four-month project, "ceremonial days" for sprint planning, review and retrospective 32 days 16 days 11 days 8 days
Impact on other team members when a member fails absent in the middle of the sprint - length of the "endurance test" A couple of days Several days More than a week A couple of weeks
Unbroken thinking time, allowing for the team to address challenges as the arise 3 days 7 days 12 days 16 days
Likelihood of falling into the "procrastination trap" None Low Medium High
Adaptation to uncertainty in story creation Many stories cross sprint boundary Some stories cross sprint boundary Few stories cross sprint boundary Rare for stories cross sprint boundary
Application feedback Best Better Good Fair
Process improvement cycle Fastest Fast Frequent Slow

Although this is not a systematic research about the topic, it should be taken as a better approach than making decisions only guided by guts. In later posts we will be telling you the results of working with one week sprint and maybe the results of a more detailed research.

[1] Deemer, P., Benefield, G., & Larman, C. (2010). The Scrum Primer. (J. Sutherland, Ed.) Development, 1285931497(1.2), 1-22. The Scrum Training Institute. Retrieved from http://goodagile.com/scrumprimer/scrumprimer.pdf

[2] Loki Astari. (2012). Confused about modifying the sprint backlog during a sprint. http://programmers.stackexchange.com/a/149892

[3] ScrumAlliance forum at groups.google.com. (2010). Can Sprint backlog change during Sprint? https://groups.google.com/forum/#!topic/scrumalliance/nw7GJ_UPkxs

[4] Haughton, B. (2011). Cognizant. Agile Scrum Sprint Length: What's Right for You? Cognizant 20-20 Insights. Retrieved from http://www.cognizant.com/InsightsWhitepapers/Agile-Scrum-Sprint-Length-Whats-Right-for-You.pdf

Acknowledgments

This post was written for Vairix Software Development, so I want say thanks to them for let me share this with you in my homepage.


Significant Revisions

Apr 7, 2014: Original Publication on vairix.com

Apr 13, 2014: Original Publication on dariomac.com

Apr 14, 2014: I've found this article that is related with the research topic (although I didn't find earlier maybe because this wasn't a systematic review). http://agilepainrelief.com/notesfromatooluser/2013/07/choosing-sprint-length-shorter-trumps-longer.html