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.

  • 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

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.

“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 the ideal world, the developer’s calendar during the experiment is going to look like this.

How to plan it?

As an experiment, I recommend a fixed time framing between 1 and 2 weeks.

  • 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

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.

With 2-3 sprints at hand, what are you going to deliver at the end?

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.

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.



Prague based full-stack developer and agile practitioner. Engineering Manager at @productboard 🚀

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josef Sekava

Prague based full-stack developer and agile practitioner. Engineering Manager at @productboard 🚀