Are you struggling to deliver within your sprints? Make them shorter!
Learn how to pinpoint your team’s problems using the two weeks long experiment.
This is a description of the experiment from the story “How the COVID outbreak accidentally kickstarted SCRUM in our IT department”.
While I was aware that the experiments like “one day sprint” exists, I had never witnessed it myself before this spring. That is when I found out how powerful short sprints really are. Where week or even two-week sprints often hide the true problems the team faces, short sprints are merciless.
- Are your working hours not overlapping enough?
- Are your tasks not clarified on the planning?
- Are you not committing and merging frequently enough
- Are you spending to much time in JIRA
- Are your builds failing often
- …
For most of these things, it’s easy to compensate them in a week. But they are a nightmare to solve when you have only two days.
If you and your team are having difficulties delivering your commitment or if an issue keeps appearing on the retrospective and nothing seems to help, consider trying this experiment.
Preparing the experiment
The general idea is simple. Make a series of super-short sprints.
How short exactly?
I recommend 2,5 days sprints or shorter. Even 1-day sprints can be done, if you can afford to clear your calendars.
Note that you will spend some time on meetings (planning, 2–3 stand-ups, review and retrospective) and with 2,5 days sprint it leaves you with roughly two workdays. That allows you to use the most powerful question:
“If I am going to start on this task this morning, will it be done at the end of the day tomorrow?”
This simple question will force you and your team to think about what is manageable. A week can be too abstract even for skilled programmers. To commit towards a deadline on tomorrow evening though, that’s different!
In my experience, the 2.5 days timebox is the maximum for less experienced developers to plan with sufficient confidence. And since the goal here is to learn to better planning, do not overstretch your sprints.
How to plan it?
As an experiment, I recommend a fixed time framing between 1 and 2 weeks.
Remember that this is more exhausting than standard “business as usual” work. There is constant deadline pressure, changing requirements and intensive communication. Bear that in mind and plan accordingly:
- limit number of “mini sprints” beforehand
- plan meetings on fixed times with the stakeholders, so you will have attendance
- for 2,5 days, 30 minutes planning, 30 mins review and 30 mins retro should suffice
- don’t plan for formal stand-ups, leave it up to the team to sync the work
- do not work on anything critical, as the learning is the main goal here
At the and, plan for an Overall retrospective. I suggest 60–90 minutes for every week of the experiment.
MVP and definition of done
Remember one thing: MVP. You should be able to release during or at latest at the end of the sprint.
You probably know the following drawing by Henrik Kniberg. Now is your time to show that you truly understand it! Do bring the value to the user at the end of the first sprint. No matter how small the value can be.
Definition of done is essential, so work on it with your stakeholders beforehand. Ask them to be unforgiving on the reviews. The goal here is to learn how to do things on a small scale. And finding out where are the bottlenecks in communication between stakeholders and the development team.
Ditch JIRA (or any other digital tool)
This might be controversial for some people. But I found out that this point significantly contributes to a shift towards more agile mindset. For the duration of the experiment, ditch your favourite digital tool. Go for simple “ToDo / In Progress / Done” board using a flip chart and a bunch of post-its.
The goal is not to get rid of your digital tool permanently. The purpose is to understand the communication around tickets. To find out what information needs to be written down, what can be passed around verbally and what information you need during and after the sprint.
If you are restricted from doing so, you can always fill your digital tool retroactively.
Running the experiment
Good, now you are ready to start your focused short sprints. On plannings, focus only on the sprint at hand. On your retrospectives, focus solely on the last short sprint. Leave the learnings from the experiment and the transition to your “business as usual” mode for the Overall retrospective.
Overall retrospective
Once you close the final review, do the Overall retrospective. On this retrospective, focus on the bigger picture. Take written notes from this meeting and save them somewhere online, so your team can return to it in the future.
Closing the experiment
I recommend returning to the learnings in a month or two, to make sure that you are using the newly gained knowledge and to reflect how it changed you as a team.
Have you found anything interesting? Please share!
