One Week Work Sprints In New and Changing Environments

Life is a marathon, not a sprint and in the end the race is only against yourself

Recently, my team changed from 2 weeks down to 1 week sprints. Overall, our team is happier and we found that this duration of our sprint worked best with the type of work we were delivering for our organization. This experience is the basis for this post.

Background Context of Day to Day Work

Prior to 1 week work sprints, we operated under a two week sprint. Our team, was constantly juggling lots of projects which had lots of dependencies with other teams. Often we would uncover unexpected work in the middle of a sprint. Given the size of our systems/infrastructure (our app easily serves 200m+ users in traffic) and the geographic distribution of some teams, these unexpected changes could take 1-3 days worth of work to close out completely and derail some core feature work. This story should feel familiar to a lot of software engineers.

During sprint review meetings, as a team we were only closing out between 50-75% percent of our work tickets consistently (we can get into another whole debate how how to measure effectiveness, but hear me out) and it was a noticeable pattern, so it got us curious. We also observed there was lots of cramming of work in the last week of the sprint, which made for a stressfull non-enthusiastic work environment to be in (people skipping lunches, crammed code reviews).

Part of what made 2 week work sprints difficult for was:

It was way too easy to fall in the trap of being too optimistic and underestimate how much time a task would take.
There were lots of new people on our team
New technologies being learned and mastery in certain areas currently being attained

Why We Decided to Move to 1 Week Work Sprints

it allowed us to course correct, reprioritize work and reallocate resources more easily during planning
More intention and focus with prioritization and planning
Less cognitive load on individual contributors (focus on this week)
faster feedback cycles

Before Making the Change

Before making this shift, one of things the my engineering manager did was reset expectations in psychologoically safe manner. To paraphrase

this is why we are doing this (providing context, history)
this may work or it may not
this is a marathon not a sprint. We expect to see these benefits of the changes over months.

and probably the most important one I feel, and is often left unsaid on engineering teams, when its better to remind people of this explicity:

We don't expect you to finish everything in your work sprint every time. We work in a creative, not procedural environment. As long you do your best, we trust with time these faster feedback cycles will help everyone. Some weeks we may crush our goals and other weeks we may not make the progress we initially expected, but over the long term, we think things will normalize.

Reasons Why I Enjoy Working Under 1-Week Sprints:

Sprints are short, focused and your less likely to find yourself multitasking
Planning & estimating time is hard in software! 1 week sprints can serve as a method to help you think about the most important items to complete every week.
In my experience, during team meetings, it's easier to break down work and get better estimations, especially if you have other engineers present with context of the work in the meeting to gut check, fact check and brainstorm with you
I feel less stressed. I come in every week focused and with the end goal in mind.
You can gather insights and patterns about yourself and your team environment much quicker
It can lead you to be more more naturally intentional and proactive with your interactions.
It's harder to put off asking for help early and often when your sprint is only 1 week long.
If you notice your team consistently over-promising work, you can catch that quickly and adjust the amount of work your taking into the sprint the next week.
If you're a team lead or scrum master, you can use these data points (which you're gathering quickly compared to 2+ week sprints) to get a sense of what to timelines to share with your business stake holders for progress updates.
Less cognitive load. It's mentally easier to think about just 1 week worth of work.

Common Questions I've Recieved Around 1 Week Sprints

When does your team do sprint planning?

Every 7 days. The specific day doesn't matter too much as long as you commit to keeping the cadence with your team.

Isn't sprint planning once a week time consuming?

Our team only holds this meeting for one hour. We've set an expectation for everyone to come in prepared with updated sprint items and ready to talk about any spill over sprint items or blockers.

Do you practice all of Agile?

Currently, our team doesn't have a separate sprint review or sprint retrospective meeting. We tend do all of that in the sprint planning meetings on Monday in a very succinct manner.

Should You Change Your Sprint Process?

Before making any changes, you should evaluate and see if there's a strong reason to change what you have already. Take into consideration the context and environment in which you're team operates. What type of environment do you work in?

are you feature driven public facing product?
are you in an A/B testing environment where you are frequently releasing new features?
are you on an exploratory research based team where you can't force progress because you truly can't estimate how long it will take to make a discovery?
is your work link to many other team's systems & infrastructure or is your team fully indenpendent and mostly self contained?

Deciding between a 1, 2 or N week work sprint should be something that's discussed as a team. I honestly don't think there is a correct answer to this. You might find, like our team did, that questioning if the current way we were doing things made sense, or if were we just doing what others before us did.

Interesting Thoughts from My Friends

I like one week sprints too. It forces stakeholders to breakdown user stories more thoughtfully and helps to define the scope of work better.
For engineers, in longer sprints, its too easy for (people not involved directly in the code) to slipping in extra work/features because the perception is that there's more time (without factoring in the extra things devs have to do to make sure the features are stable like testing).

How does long is your team's work sprint? Do you think 1-week sprints would be effective for your team?