Be more agile with new sprint permissions

We want teams to succeed and make awesome software. This can be achieved through agile best practices, but it doesn’t hurt when your tools make things easier and more effective for every member of your team.

Cue the music for one of Jira Software’s new permissions: manage sprints. Keep reading to learn more about permissions and how they function behind the scenes to affect every member of your team. I’ll also provide an overview of how manage sprint permissions bring simplicity to planning and tracking work, remove overhead, and minimize risk for everyone – no more single points of failure and instead an environment in which the entire team can be more agile.

Jira Software permissions 101

To understand how the new sprint permissions work, let’s take a step back to understand permissions in general. In Jira Software, permissions are what we call settings and they control what users can see; whether or not you’re an admin, they affect you and the way you work. Permissions range from settings that limit who can create a new project, to whether or not a user can comment on a particular issue type, to what group of people can change the design of a workflow. Permissions also exist in a hierarchy of three:

• Global permissions: These apply to Jira Software as a whole, not individual projects (for example, whether users can see other users).
• Project permissions: Organized into permission schemes, these apply to projects (for example, who can see project issues, create, edit, or assign them). Project-level permissions help you set what users can do within a project.
• Issue permissions: Issue permissions refer to the level of visibility individual issues have for certain team members or certain roles. For example, issue permissions lets you set up types of issues so that they can only be seen by project admins.

You might notice that something is missing from this hierarchy: sprint permissions, which are also known as sprint responsibilities (think starting or stopping a sprint, or editing sprint information). Historically, sprint permissions were limited to project or global administrator permissions. For most teams this typically manifested itself at the role level and teams relied on someone in a product manager, development manager, or team lead role to create a new sprint, or reorder future sprints if there was a mistake in dates (sound familiar?).

Despite the fact that maybe your team, and definitely teams at Atlassian, rely on these roles to curate and run sprints, it didn’t make sense that the entire team couldn’t perform these basic responsibilities. Part of being agile and working on an agile team is the ability to work cross-functionally and share ownership. These permissions were a part of an administrator’s project permissions, to minimize risk, but escalating problems relating to sprint responsibilities became a huge blocker for teams.

Part of being agile and working on an agile team is the ability to work cross-functionally and share ownership.

Tweet

If a product manager or team lead was out and the team needed to close a sprint, they needed to wait on that person to return (or find another person with the right permissions). To remedy this and give teams more control over how they work, sprint permissions were created and the feature in Jira Software is called manage sprint.

Sprint responsibilities and management

The new sprint permissions solves most of the above problems by doing two things: 1) enabling teams to better organize how they work with sprints, and 2) bringing a new level of trust to how teams and how individual team members tackle sprint responsibilities.

But, before you decide how you want to approach the new sprint permission, here’s a list of the sprint responsibilities opened up by the manage sprint permission:

• Creating sprints
• Starting sprints
• Completing sprints
• Editing sprint information (sprint name and dates)
• Reordering sprints (currently only future sprints)
• Deleting sprints (currently only future sprints)
• Reopening sprints
• Moving the sprint footer

For those already familiar with permissions, the above list might seem familiar as they’re basically the existing administrator project permissions. For those less familiar with permissions, think about manage sprint permissions as opening up doors to help your team become more agile.

[WPGP gif_id=”33451″ width=”600″]

For example, if you’re in a sprint planning a meeting and ask yourself “What’s the estimate for the sprint looking like?” because you feel nervous about the amount of work to be completed in the upcoming sprint, instead of waiting for someone with permissions to move the sprint footer you can follow along in the sprint planning meeting and validate your concerns to see that everything is going to be okay or that an issue needs to be re-evaluated.

Sprint permissions best practices

If you’re an existing user and feel comfortable with permissions, approach sprint permissions by thinking granularly around how your team works with sprints. (Note, that with this new feature, anyone in the administer project membership will automatically be copied over to the manage sprint permissions.) Do you need the project administrator to be the gatekeeper of starting and stopping a sprint? Or do you want to open that up to a group of people like scrum masters?

A common use case that would argue for the latter is if your team works with a contractor like a hired scrum master or agile coach. If said person needs permissions to edit sprint information, but you don’t want them to have permissions to edit versions or components in a project, then you can give them sprint permissions to minimize their impact on the project as a whole.

This use case might not apply to your team, but it gives you an idea of how to think about using sprint permissions. Who on your team do you want to be able to reopen sprints or complete them, but not change project infrastructure? At Atlassian, this usually means that we give sprint permissions to the whole team, because we trust everyone on the team to do the right thing – the team should feel that they have the power to move forward and work through a sprint if a product manager or a team lead is out. In order to be agile, we need to move quickly and continuously deliver software.

This new permission also helps the whole team take more ownership of the sprint that they are working on day in and day out, while giving benefits to project and global admins, too. This fine-grained control removes a lot of internal support requests and at Atlassian this is a big (awesome) deal.

Look at where permissions are holding your team back — if at all — and see how this new level of permissions could help your team work the way they want.

If you create a new instance, then manage sprint permissions, by default, will be enabled for all projects and every user will have the ability complete each sprint responsibility listed above. This is great for new teams and/or new team members that don’t need to lock anything down.

Sprint permissions means better agile development

By setting up a new level of permissions that connects sprints and boards closer together, we’re bringing agile principles to the forefront of how you set up your experience in Jira Software. Running a sprint is a core agile ceremony and a team effort. So are other agile ceremonies associated with a sprint, like sprint planning, stand-ups, and sprint reviews. Each of these ceremonies, to a certain extent, rely on certain sprint permissions. In a sprint planning meeting you need to be able to use the sprint footer to estimate, and then when you’re ready, start a sprint. When a sprint is running you sometimes need to edit information about the sprint like the name and dates. Or reopen a sprint if it was accidentally or prematurely closed.

Also, it’s pretty common for product managers and development managers to look ahead and try to organize future sprints by moving backlog items into different sprint backlogs without realizing that the future sprint already exists (in this case you would need to delete the duplicate). Manage sprint permissions remove a lot of the blockers that would prevent team members from performing these actions. Above all, it’s the responsibility of the team to figure this out.

Learn more about sprint permissions