This is the third of several posts regarding Scrum in which I would like to share some of the things we learned throughout while using Scrum. Sprint planning is amongst one of the most crucial decisions to be made.

Deciding your sprint duration is an important decision. When a team starts a project using Scrum, the first question is, “How long should sprints be?” It depends on multiple factors like estimated duration of the project, experience handling project with Scrum and technical capabilities. If you choose a length that is too long, it will be hard to keep change out of the sprint. If you choose a length that is too short, the team will struggle to complete their work in the given time.

And with time, you realize that there is no particular size of sprint that everyone follows. The best advice is to consider what the team is comfortable with, in our case, it is two weeks for a project duration of three months. However, if a sprint is more than four weeks, it is no longer a sprint.

In our observation, it is better to go with shorter sprints (one to two weeks) as they help solve problems/implement faster. The biggest advantage of using Agile is to get all the problems in front which is feasible only with a shorter sprint cycle.

Be careful of Dark Work

In Scrum, dark work is any work that is not intended to be done in the current sprint but is picked up and done without informing the team and updating the board.

This is a primary reason why shorter sprints are recommended because the longer the duration of a sprint, the more dark work your team might pick up. It leads to a motivational challenge for the team members as they know that they have done more work but it does not reflect on the storyboard.

Sprint retrospects and reviews

A longer sprint duration means longer planning sessions. With an increase in the length of the planning session, team members lose focus. For a three to four week sprint, the planning meeting gets stretched beyond time. This also means that there are fewer sprint retrospects which lead to fewer opportunities for change. Sprint reviews are also widely spaced which affects the product owners opportunities to improve the product.

However, there is no harm in going for longer sprint sessions that span over three to four weeks. They are easy to start but have a number of disadvantages associated with it:-

1. It is difficult to plan well in advance as the duration is too long. It leads to taking up more dark work.
2. The sprint turns in mini waterfall i.e analysis, development and testing with a certain number of days allotted to each.
3. Problems are addressed at a slow pace.
4. Lack of focus.
5. Fewer sprint reviews and retrospects leading to few opportunities to improve.

On the contrary, a shorter sprint cycle has a number of advantages to it. Here are some of the pros and cons.

1. Sprint retrospective happens at a higher frequency which gives the team member a large number of opportunities to try smaller changes increasing the learning ability of the member.
2. Frequent product reviews give the product owner more chances to incorporate changes.
3. Any slowdown is highlighted quickly as a specific number of features are to be completed by the end of every sprint.
4. Shorter sprints lead to easy planning and reduce the amount of dark work.
5. It increases visibility as the team can break features into smaller chunks giving the product owner control over prioritization.

1. Getting the work done in a two-week sprint can be tiring.
2. Every day scrum meeting is too much overhead for a one week sprint. They scale linearly with the length of the sprint.

Reaping the benefits of Shorter Sprints

Getting early feedback:
However, shorter sprint length helps reduce the entire feedback cycle. The user stories are usually available for review by the end of the sprint. The number of stories developed in a three to four-week sprint makes it difficult for the management to determine the project quality and plan for bug fixes in the next sprint.

In short sprints, feedback comes more quickly and is relatively briefer. I have observed that teams working on short sprint are in touch with what they have implemented just a week ago, so they can make quick changes.

Comparing this with a four-week sprint, when the developer develops something in the first week and doesn’t get feedback until the fourth week; here you can see a delay of three weeks in which development members might need to invest real effort to focus again on a task they finished three weeks ago. So more time is needed to implement feedback compared to that required by shorter sprints.

Remain connected:
Short sprint lengths keep the client’s involvement active. They are involved continuously for PB prioritization, requirement gathering, and reviews, and these frequent activities keep their interest alive.

Decreased planning difficulty:
For short-duration sprints, we have fewer stories compared to four-week sprints. A large volume of user stories requires follow-up meetings about prioritization, understanding, defining acceptance criteria, brainstorming. This involves too many stories and meetings that are too long to remain organized. So planning is easier if you implement shorter sprint lengths.

Team performance:
While observing statistics of team performance, such as velocity, the focus factor, team capacity, found work, adaptive work, and accuracy of estimation, these stats are in favor of small sprint lengths.

Regarding team satisfaction:
If you measure the happiness index of the team over a period of time, comparing two-week and four-week sprints, the team with shorter sprint lengths will deliver more with good quality, which gives them higher team satisfaction and morale. In two-week sprints, teams start feeling more focused; they can remember most of the sprint user stories easily, and it is easier for them to communicate their status to each other.

Today most teams go for shorter sprints of two weeks and some even prefer one-week sprints. Scrum is about faster feedback and shorter sprints mean faster feedback and continuous improvements.

Once you realize the benefits of shorter sprints, you can cut down on dark work by planning shorter sprints. You can start by breaking down the stories to achieve quality over quantity. Position yourself better not only in terms of planning but in increasing confidence ultimately. Shorter sprints will increase the team’s productivity and help you deliver a good quality product.