While describing the Scrum framework, the Scrum Alliance’s official guidance niftily nudges scrum practitioners towards shorter Duration sprints.

This post is about the experiences and observations made within a few of the projects I have worked with and the impact duration of the sprint has had on the overall output.

Timebox Considerations

We’ve all been there, whenever a team begins a project using Scrum, one of the first questions that often arises is, “How long should the sprints be?” This would always depend on a large variety of factors like:

-Expected/estimated duration of the project.

-Experience with Scrum which applies to both the Scrum team & stakeholders.

-Technical capabilities (TDD, automated deployments etc.)

And in due time we realize that there is no one-size-fits-all, magic bullet for determining a sprint length that works well for every team. So best advice at times like these is to start with the timebox duration the team is comfortable with, which in our case I’ve observed is more often 2 weeks.

Timebox pitfalls

It’s common for unseasoned teams to pick a timebox at the longer end of the scale because they often worry how they could perform design, development and testing within a shorter period and produce a quality product. It’s driven by the thinking that if they have more time, they will be able to accomplish what they commit to.

But wait, what I am about to tell you is something my team and I have learned after several planning, review & retrospects. “Shorter Sprints (depending on your current sprint duration, one to two weeks) help reveal problems/impediments faster.” Because you know what? This is what Scrum is intended to do for you, bring the problems to the forefront!

Beware of Dark Work

In Scrum terminology, “Dark Work” is any work that wasn’t intended to be done during the Sprint that is picked up and done without being surfaced to the team and placed on the board.

And surprise, surprise – the longer the duration of your sprints are, the more dark work your team ends up doing. This leads to a major motivational challenge, the team knows that a good amount of work was being done. Yet, it is not showing up anywhere, not on your boards, not the velocity or burndowns.

A Pattern Within Retrospects

With due course, we began making many realizations, like:

It is more difficult to plan for a longer duration sprint compared to a shorter sprint. The planning meetings tend to be longer, they are marred with people losing focus while planning.

This also means if the duration is longer, there’ll be fewer Sprint Retrospectives, which would lead to fewer opportunities to improve.

A general loss of focus in the team.

Not only the team, because Sprint Reviews and/or demos were widely spaced, it gave the Product Owner fewer opportunities to improve the product.

A little change, would do you good

Once we realized and decided to cut back on the dark work, and eliminating the desire to seek more time on our hands we started working on breaking down the stories. Enlightened with the wise words of Bill Wake, INVEST in Good Stories, and SMART Tasks we positioned ourselves better, not only in terms of planning but we ultimately gained the confidence that, what we are doing by reducing the sprint timebox duration is going to increase the quality and productivity of each sprint and ultimately deliver a top notch product.

Reaping the benefits

Continuous Improvement

The biggest benefit we reaped is the most talked about promise of Agile- continuous improvement. Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.

Better Planning, ergo; Far Less Dark Work

Shorter cycles make planning easier, which increases focus and reduces the amount of dark work.

More power to the Product Owner

Because the team must now slice Stories or Features into smaller chunks. It increases visibility and gives the Product Owner better control over prioritization and de-prioritization as well as quick and early feedbacks from them.

Better Connect

The Product Owner and the team are more proactive while working on shorter sprints. A continuous Q&A flows between the team and Product Owner, helping make everyone a lot more involved/engaged.

Better Performance & Learning

With proactive seeking of clarity, work estimations. Therefore, delivery of the user stories and tasks become faster and thus enhance the overall performance of the team.

Meetings and Retrospectives

With shorter sprints the ability to plan in less time becomes second nature.

I hope I was clear and concise in explaining why short sprints are beneficial. Do you have any thoughts on the same? Please share in the comments below.

Thank you for reading.