As per Scrum guidelines, sprints last anywhere between one and four weeks. The team needs to decide on sprint length based on its comfort level and the required feedback loop frequency, and the team needs to keep that same pace going until the project ends.

Scrum teams tend to start enthusiastically with two-week sprints. After after a couple of sprints, though, they often start complaining about lack of time and look for increased sprint length. When we probe about why this happens, we get all sorts of reasons. But the real issue tends to be the need to restrict work for two weeks.

Following are some questions teams can ask themselves so they can make informed decisions about whether to increase their sprint lengths:

  • Has the team been trained in XP practices such as refactoring, mocking, simple design?

  • Has the team explained XP practices to the PO? This will help him or her write smaller user stories with clearer acceptance criteria.

  • Is the PO using appropriate user story splitting techniques?

  • Are user stories planned to cover the entire sprint (filling all available time)?

  • Are functional user stories built incrementally across sprints?

  • Are user stories following vertical slicing (functionality covering all layers/tiers of the system)?

  • Are user stories small enough to be completed in couple of days? (A rule of thumb is that any user story should take two to three days for completion.)

  • Is trust established among team members, so they can rely on each other’s updates in daily stand-ups?

  • Does the Definition of Done list all activities that the team needs to ensure that user stories are complete?

  • Do teams have CI, CD frameworks in place to reduce manual effort?

  • Are teams updating the ALM tool properly to project status correctly?

  • Are teams appropriately loaded to capacity?

  • Is extra work being done that is not part of the ALM tool?

  • Is the ScrumMaster actively working on the impediment backlog?

  • Are infrastructure issues addressed as a part of Sprint Zero, or are they actively worked on by the ScrumMaster with appropriate stakeholders?

  • Is the team working on retrospective action points to help them move along?

  • Is the team highlighting the same improvement areas for several consecutive sprints?

  • Are intermediate demos of user stories helping the team?

  • Does the ScrumMaster invite changes during sprint execution?

  • Are product backlog refinement meetings happening in an effective way?

  • Is the team looking at technical debt for each sprint and working on it?

  • Is automation test creation complete for all previously delivered sprints?

  • Is the testing team using appropriate testing strategies — risk based, exploratory testing — or using appropriate Agile testing quadrants?

  • Are testing team members proactively involved in user story testing?

  • Are dependencies called out well is advance and are the right teams engaged to work toward delivery?

  • Is the team taking technical spikes to any investigation/ functional exploration to ensure that all required inputs are available for actual implementation?

  • Is the team committing based on “weather” (the previous sprint’s velocity)?

  • Does the DOD list all activities the team needs to ensure that user stories are complete?

  • Are sprints turning into Waterfall exercises?

  • Is the product manager acting as ScrumMaster on Agile projects, with a traditional project manager’s mindset?

  • Is the ScrumMaster working as a true servant leader to the team?

  • Are there always lots of suggestions/changes discussed during sprint review meetings?

  • What level of documentation (design/user manual/infrastructure) is required during the sprint? Based on the outcome of answers to these questions, my recommendation would be to prioritize the problematic areas, work on solutions, and if they don’t work well, only then should the team investigate the option of increasing sprint length. Again, it must be a team decision to accept the risks associated with increased sprint length.)

The list above is not exhaustive and complete, but it can provoke the team’s thinking. Based on their projects and the nature of the work they are doing, the team can add additional points that they need to explore.


About Author

Alhad Akole
Zensar Technologies Ltd

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


Posted by Alhad Akole

Leave a reply

Your email address will not be published. Required fields are marked *