One Week Sprint

We have one-week sprints. The team suggested increasing it. I have a feeling that a one-week sprint is better, now I need to convince the team this is true.

From the top of my head I believe that a shorter cycle gives us two things:

  1. Faster changes in priorities
  2. Less overlapping due to many parallel tasks taken for a longer period.

Some things to consider here are that we already have unpredictable tasks that are coming from support, so we have already modified our sprint plan in the middle of it. Also, we do not do retrospectives, and planning is not taking a lot of time, so I would say that we have 4.5 days per sprint.

The potential problem I see right now is that priority is not always respected. That is seen when someone takes multiple less important but as it turns out complicated tasks and pushed important tasks for the next week.

Research (Two-week sprints)

With a two-week sprint:

  • Longer meetings if we have 2 weeks sprint, planning is longer, reviews will accumulate and take longer, etc. link, link

  • Possible "slack off" time at the beginning of each sprint, when you know that you have 10 days to finish your tasks. I don't think this applies to us (maybe subconsciously)

With one-week sprint:

  • we are encouraging splitting features. Why: Force us to strip down new features into the real MVP that can be delivered to customers: link.

  • It is almost impossible to add unready tasks that would say "Design will be ready in few days" link

  • Larger investment in planning link

  • When iterating in short cycles, the weakest part of your process becomes an immediately apparent link

  • Arguably, with a short cycle repeating processes that can be automated become apparent.

  • Easy to derail a sprint (Unplanned changes have a larger) link

  • Less time to stabilize the product

There is a good idea, and that is - to try it out. The problem I see here is that we don't have a retrospective (I imagine retrospective as an evaluation of the previous week, seeing what was done, what wasn't, speed, etc.) or some referent value to compare to. Everything will be subjective.

One more link

Interesting things

  • 80% of teams are using two-week sprint
  • There are many affirmative articles about moving to a one-week sprint :)
  • Better teams work in one-week sprints link

Questions I have

  • How do we define a successful sprint
  • What metrics do we have and which metrics do we want to improve?
  • What problems are we solving by changing from 2 to 1 week?
  • Because we sometimes have sprint interruption - tasks in the middle of the week, are we using the ultimate sprint length of one day? :) Check this interesting talk.


The fact that we are already on a one-week sprint schedule means that we are good. And based on these articles it seems that two-week would be regression.

  1. We as a team need to decide what works for us, so nothing above doesn't matter if we all do not agree on it
  2. We can test it, but the test should be well defined


I plan to write more articles about common laravel components. If you are interested let’s stay in touch.
comments powered by Disqus