Teams new to scrum face lots of decisions – one critical decision for teams to perform efficiently is determining sprint length. Every team's needs are different, and there's rarely a one-size-fits-all approach to planning the length and organization of your sprint.

What is Scrum? How long should sprints be?

What is Scrum? Scrum is an Agile framework that gives teams guidelines on how to complete their work. It contains sets of roles, ceremonies, and considerations for how your work is completed.

An Agile sprint is a concept in scrum that represents a time box, i.e., a short amount of time the team has committed to complete the work. And how long is a sprint in Agile? Sprints in scrum can be as long as you want; however, it's most common for sprint length to be between 1 and 4 weeks. Teams running Scrum sprints need to decide what makes sense for them.

We often see that team's first instincts lean toward the extreme: Either 1-week sprints or 4-weeks sprints. While there are arguments for the varying lengths of sprints in scrum, here are some standard variables that you and your team should consider.

Sprint Planning for Planned vs. Unplanned Work

Before sprint planning begins, it's essential to define what you want to accomplish during that sprint. Instead of using overarching strategic objectives to guide your team, sprint goals should be smaller, more attainable chunks of work that can be completed in a shorter timeframe. 

If you are an Agile Scrum team with high variability in your work, longer sprints may give you the necessary buffer to complete the job. If you've got a 1-week sprint (with 1 of your 5 days already dedicated to ceremonies), even one or two random pieces of work can prevent your team from completing the work in the committed scope.

On the other hand, if the team has unplanned work with a lower level of urgency, Scrum sprint lengths that are shorter allow you to include the work in your Scrum sprint planning within a shorter period.

As far as how to best manage work, Jira is a great tool to help teams achieve this. Here's a guide on starting, managing, and completing a sprint using Jira. 

Time Dedicated to Scrum Ceremonies

How much time per week should sprint planning to be spent in scrum, retrospectives, backlog grooming, and demos? Shorter sprints mean more time is spent in these meetings. This becomes even more essential if you do not have dedicated roles (scrum master, product owner).

What we see in 1-week sprints is that teams can lose a full day (twenty percent of the sprint!) of each sprint to demos, retros, and planning. So the shorter your Agile sprints are in scrum, the more often you're having these ceremonies.

Size and Scope of Tasks

Is your work small enough to be completed in the sprint length? For example, if you are often not completing work in 1 sprint, a longer sprint in scrum may make sense (or you may just need to work on improving properly sizing your tasks).

Feedback Cycle

How often do I want to see and evaluate completed work? Is it acceptable to go 4 weeks without demonstrating the work that's being done? Do you need to know every week? Sprint length determines how often you see sprint demos and complete sprint retrospectives.

Inspection and Adaptation

There's no one-size-fits-all answer to optimal Scrum sprint length, and iteration is the key to scrum - so don't worry if your first choice doesn't work for your team. That's what your retrospectives are for, after all!

For more background on how we do Agile at Scale, read our case study on how Praecipio Consulting helped an enterprise client accelerate their Agile transformation.

Is your organization going through an Agile transformation? Learn about this robust framework and how our team can help your organization drive successful business outcomes through our Agile at Scale implementations. 

Please reach out if you have questions or are considering how to migrate your team to an agile approach.

Jira is a great tool to help development teams manage their work. Because flexibility is one of many "flexes" (pun intended!) that Jira has, each Dev team can easily configure their boards to best suit their workflow. Jira currently offers two types of Agile boards, Kanban and Scrum. 

Scrum is a more structured Agile approach. Scrum sprints have a quicker cadence, which forces more significant projects to be broken down into smaller stories/tasks. In addition, planning, review, and retrospective meetings are spread throughout. Check out our Scrum Master Basics series to get the low down on how to become a Scrum Expert.

Kanban boards are all about remaining flexible and improving on the iterative process. As a result, Kanban boards are better for teams with various changing priorities and projects. Unlike Scrum, their sprints are less rigid in length and allow you to shape its structure depending on team needs. Learn how to set up the best Kanban boards here.

Both boards can use backlogs, but Scrum boards also allow the teams to track their work in Sprints. Keep on scrolling to learn step-by-step instructions on how to create a sprint in Jira and set your teams up for success with Agile project management.

Do You Have Permission?

Creating sprints is controlled by the Jira project's "Manage Sprints" permission. It is a good idea to limit how many users have this permission. Typically, this permission is reserved for Jira Admins, Project Admins, Product Owners, and possibly Scrum Masters. The "Manage Sprints" permission controls which users can create sprints, edit the sprint properties, start sprints, complete sprints, and delete sprints.

Creating a Sprint

Once you have the "Manage Sprints" permission and are ready to create a sprint, go to your board backlog and click Create Sprint. If you do not see the Create Sprint button, chances are you do not have the Create Sprint permission for that project. Check with your Jira Admin or request "Manage Sprints" permissions.

After you click Create Sprint, the Sprint will automatically be named after your board, Board Name Sprint 1, and each subsequent Sprint will increment the count by one. 

Starting a Sprint

Go to the backlog and look for the Start Sprint button when you are ready to start the Sprint. Traditionally, teams will only run one Sprint at a time. You can change this in the Global settings if your group allows parallel sprints. Once you click Start Sprint, a window will appear for you to check or set the start date and the duration.

Completing a Sprint

Complete the Sprint as scheduled. Any unfinished work or work not in the far-right Done column will be added to (rollover) the next Sprint. If future sprints have already been created, you will see the next sprint name. If no future sprints are available, Jira will create one using the Board Name and the next sprint count. There is a reason why they call it an Agile transformation journey.

The constant evolution of teams, marketplace demands, and business requirements is certainly an adventure. Let us be your guide as you navigate this journey! Reach out to us and see how we can help your organization implement best practices for building Agile teams.

A sprint retrospective is, in practice, a meeting scheduled after every 1-2 sprints in which the team comes together to discuss how to improve the way they work. The meeting can follow several formats, with the most common consisting of each team member sharing what is working well, what isn’t working, and any new ideas they have to improve. Some examples of takeaways from the meeting might be “Our daily standup is helping to keep everyone on track,” “We need a better process for reviewing tickets after QA is finished with them,” or “Let’s try estimating with story points instead of time values.”

Retrospectives were introduced to make sure the team is constantly in communication about how to improve. This process is commonly known as a feedback loop, and is one of the hallmarks of any good Agile process. Feedback loops have been discussed as one of the most important parts to becoming successful, either as a team or as an individual, a claim backed up by copious amounts of business literature full of research and examples on the topic. A prime example of this can be found in Talent is Overrated by Geoff Collins. While not a perfect book by any means, Collins does a wonderful job of explaining the importance of feedback loops. The argument posits that the way humans improve at anything is to do the thing, look back on the thing and analyze it, figure out how to improve performance of the thing, then do the thing again. The retrospective helps teams to do the middle two parts of that process.

Here are some tips for running a successful sprint retrospective:

Get on a consistent cadence

Doing retrospectives too often will lead the team to resent them. Doing them not often enough will greatly reduce efficacy and result in an inability to put into action the ideas brought up in the meeting.

Prepare ahead of time

Before the meeting, encourage team members to spend a half hour thinking of what is working well, what isn’t working so well, and ways to improve. That way the team can most efficiently use everyone’s time when they come together for the retrospective.

Bite off what you can chew

Instead of trying to implement all the new ideas after every retrospective, focus on determining which ideas are the quick hitters: those that have a big impact, but are easy and quick to implement. By adding the one or two best quick hitters each week, the process will evolve at a sustainable pace. Over time, the team will likely run out of quick hitters, giving you a chance to implement the more intricate ideas. 

Are you making the most out of your teams? If you need assistance with Agile, get in touch, we'd love to help.