Table of Contents
Need a fast answer for the question, "What is the rationale for scrum teams implementing short sprints?" here you go...
The rationale for scrum teams implementing short sprints is to get more feedback and limit schedule risk.
Shorter sprints mean your teams get Sprint Reviews more often, which, is valuable because Sprint Reviews are when customers give you feedback on your product.
The schedule is de-risked because you are less likely to build the wrong thing. With more feedback you can be sure your effort is valuable.
Level up your agile and get professional training.
The one big thing
Picking the right length of time for your sprints is very important because you will live with that decision for a long time. You keep a constant sprint length from sprint to sprint.
Do you know what else is important? Becoming a Scrum Master, checkout our post on that topic, how to become a Scrum Master and don't forget to check out how to certify your entire team as scrum masters
When in doubt, just go with one-week sprints.
The full story
If you want to know why teams choose short sprints, keep reading this post.
You may also be curious what is the rationale for scrum or what is the recommended length of an iteration
OK, ready to start?
Why shorter sprints are better for development teams
Let's learn why the professionals prefer (and recommend) shorter sprints for your Scrum team.
In a nutshell, the rationale for scrum teams implementing short sprints is to get more feedback.
Here's a concrete example. If you do one week sprints guess how often you get customer feedback?
Once a week.
If you do four-week sprints guess how often you get the same customer feedback? Drumroll please...
That's right, every four weeks.
I don't know about you, but I'd like to hear from my customers more often.
If you'd like to learn more about how to make the best use of your time with your customers I'd highly recommend the post, Triple R: a new technique to accelerate your progress (the images below are from their excellent post).
Getting more customer feedback puts you on the "skateboard ramp" as shown by the CRE table below and keeps you off of the "cliff".
What that means is that more customer feedback ensures your project meets your customers expectations.
OK, let's learn more about how sprints fit into the Scrum framework.
What is a sprint
Sprints and time
A sprint in Scrum is a fixed duration of time in which the product owner and the development team work together to create a new or improved product. A sprint is typically between one week and one month.
A sprint is a time-boxed period of time (usually one to four weeks) during which the Scrum Team collectively works on a set of tasks.
A sprint should be long enough to allow the team to complete the work, but short enough to avoid getting mired in details.
The length of a sprint is typically one to four weeks. The Scrum Team decides how long each sprint will be, based on the amount of work that can be accomplished in that time.
A sprint may be as short as one week. The length of a sprint is usually one to four weeks, but it can be longer or shorter when appropriate.
he Scrum Team decides how long the sprint will be, based on the amount of work that can be accomplished in that time.
Sprints and teams
A team works inside of the Sprint. This is a key concept.
The sprint is where all the work happens. Said another way, the team does everything inside the sprint.
The team owns the sprint backlog and therefore the team manages the sprint backlog.
A team’s goal is to deliver value at the end of the sprint. The purpose of a sprint is to deliver marketable software.
Based on my experience, I would recommend this approach to any size organization. Even if it's a large enterprise, teams of small and large sizes can follow this small team approach to creating working software that helps the organization run more efficiently and make more money.
Work and short sprints plus rationale for scrum teams
Short sprints let you iterate more often. Iteration allows you to test, explore, learn more. All this adds up to a powerful truth, shorter sprints let teams accelerate faster and learn more.
Scrum lets teams learn and iterate making them more effective. Learn more about the rational for scrum teams.
Here's how a team delivers work inside of a sprint,
The project lead for a sprint describes the problem, vision, and solution.
The team brainstorms solutions, the team chooses a specific set of possible solutions to deliver in the sprint, and then work on them.
By the end of the sprint each solution must be production-ready.
No further work starts until the team completes these solutions. Then we demo these briefly to demonstrate their viability, before closing the problems with no more work needed on them for now (a problem closed is a good feeling). We typically produce about two new solid working features per sprint.
Some teams repeat this process to get multiple features done per sprint, although we normally aim for 20% more than this in order to have time for fine-tuning and quality assurance before releasing a product or feature into production or development environments!
Many teams also start new projects mid-sprint. All work however must come from inside a single project's backlog as stuff can't move between projects mid-sprint.
Each project gets one storyboard that shows all of its stories (deliverables). If that doesn't make sense be sure to check out how to implement Scrum.
This allows everyone in that project to see how everything fits together into some form of overall vision creation.
The key ingredient here is that while we focus only on delivering stories through iteration we try never to add anything else new unless it's part of another ticket that is already planned.
Always focus on completion of tickets related directly to solving real user problems rather than other stuff considered important by people inside or outside our organization...even if related technically!
An iterative approach works best when we have a good relationship with our clients. Communication is the key
Scrum
Sprints typically last between one and four weeks, and they include several key events, including:
- Sprint planning: A collaborative event in which the team decides what work will be completed during the sprint and how it will be accomplished.
- Daily scrum: A 15-minute time-boxed event in which the team meets to discuss progress, identify roadblocks, and plan for the day ahead.
- Sprint review: A collaborative event in which the team demonstrates the work that has been completed during the sprint and receives feedback from stakeholders.
- Sprint retrospective: A collaborative event in which the team reflects on the sprint and identifies opportunities for improvement. Each of these events is time-boxed, which means that they have a set duration and are designed to keep the team focused and on track.
How to do development in a short sprint
Now for the easy part. Short sprints work great for development work. Here are a few keys to being successful when you move to short sprints.
- Short PRs
- Clear product backlog items
- Split the product backlog items at the dependencies
- Don't change scope during the sprint
Straightforward, right?
Conclusion
In this blog post you learned that the rationale for scrum teams implementing short sprints is to get more customer feedback. This has some really amazing benefits including
- More agility
- Better customer feedback
- Align to market opportunities
- Iterate products faster than your competitors
Registered Scrum Trainer, Scrum Expert, and author
Hey, I'm Jon the owner and writer here are goagileworks. I'm a registered Scrum Trainer and a Registered Scrum at Scale trainer with over 20 years of leadership experience. I have certified hundreds of students as Scrum Masters from government, non-profit, the military, and many industrial sections. You can reach me by submitting a contact form through this site. I also write and publish at https://drink-mix-artist.com/ where I have fun helping people find great drinks and the best rum.