nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Are there any scrum practices that are essential to do scrum properly?

Dave

I recently made an update to the free Atlassian Labs app (Sprint Capacity Analysis) to add a new Overview tab.

I was concerned that my original landing page in the app (a giant table of numbers and icons) was too difficult to parse and I wanted to make it easier for users to interpret the data.

Screenshot 2025-07-24 at 9.30.30 pm.png

This lead be to wonder if there is any guidance that can be given to a team that could not be argued. My concern is that what might be "best practice" for me, might be constraining for someone else.

Jira is brilliantly flexible because it is so unopinionated. It doesn't force sprints to be the same length for example but I would argue that you need a consistent sprint length in order to establish velocity, and that you need velocity to be predictable.

Would guiding users to ensure sprints are the same length be controversial? Not for me, but I can imagine some reasons why variations might be argued for.

What about work item assignment? Is it reasonable to say that to establish accurate velocity you need a consistent team, so there should be a 1:1 mapping between board and team (which is why I created another app called Jira Board Buddy!) and that only people in that team should work on items on the board.

However, my processes are heavily optimised for achieving predictable delivery and this might not be the key objective for other teams.

The application currently provides guidance on:

Number of active sprints (ideally 1)
Overbooking sprints (planning more than can be delivered)
Delivering the expected amount of work (delivering what was possible, regardless of what was planned)
Validating assignees (they should be in the team)
Consistency of sprint length (they should be the same length)
Dividing the backlog into future sprints (there should be no unplanned work)

I thought I'd canvas the community to get some feedback. Would you argue with any of these things? Is there anything missing? I'd be keen to gauge how controversial they are.

Please let me know what you think!

Thanks,

Dave

Comments

Bill Sheboy

Hi @Dave

The first link you provided is the internal, Atlassian one and not to the public version of that app: https://marketplace.atlassian.com/apps/1238160/sprint-capacity-analysis?hosting=cloud&tab=overview

Regarding your original topic, I personally do not believe there are any best practices; instead, there are only better or worse ones to support a specific team for a specific context.

And so...if a team is applying the Scrum Framework from the guide as it was defined years ago, that might be different from the more Kanban-like guidance of the latter guide versions. Again, in my opinion, other than for small teams with basic workflow and no dependencies upon others for value delivery or management, out-of-the-box Jira has only rudimentary support for teams using Scrum or Kanban. Instead, teams need to mitigate gaps with either marketplace apps or tooling / processes outside Jira.

Kind regards,
Bill

Dave

Thanks for the feedback @Bill Sheboy (I've corrected the link, that was a silly mistake on my part - thanks !!)

So I broadly agree with what you're saying... so for example I would never say any particularly sprint length is better or worse (there are trade offs), and I do know that some methodologies advocate a number of fixed length development sprints followed by a shorter planning/review sprint. However, if one of your reasons for using scrum is to be able to forecast delivery (and I appreciate that this isn't the only reason) then have a consistent time boxed iteration to reliably calculate velocity is surely a requirement?

Also, just to be transparent... this is a personal sidebar project for me that I'm very interested in (predominantly created for my own team, but shared to to see if it has wider value) so I do think it falls into the category of an optional tool that teams could use to mitigate a gap. This discussion is purely out of personal interest rather than tied to any specific Atlassian project.

Kind regards,

Dave

@Bill Sheboy I also realised that the original discussion title was somewhat misleading on the intent of the discussion so I've changed it. Retrospectively I realise that it might have been interpreted as a question for Jira (the product) rather then individuals use of Jira (...and not even in Jira for that matter, but this is an Atlassian community! )

Apologies for the confusion - it wasn't intentional, I'm genuinely just interested to know if its possible to arrive at a consensus for absolute "musts" when doing scrum

unknown

I mostly agree with you @Dave . I would also say boards should be 1:1 with teams, only team members should work on items on that board, there should be no unplanned work (aspirational), and some type of planning iteration is needed along with consistent sprint cadences. Our agreements make sense though, since it sounds like we have similar goals in using Jira to accurately and consistently predict work delivery.

I'll jump in with a potentially hot take. I think WIP limits are a must for teams practicing Scrum. I would put WIP limits above pointing issues, in terms of things teams must do to successfully work in Scrum. I usually advocate that the absolute max WIP limit for any work stage/workflow status is the number of members on the team.

Dave

Hey @[deleted]... thanks sharing that, it's really interesting!

I've actually never really tried to force a WIP limit on teams, but I completely agree that it's a good idea. If you're trying to work on or complete too many things at once then you're increasing the chance of not completing any of them!

Limiting to the particular status of a workflow also makes a lot of sense as we definitely have in progress statuses where you cannot progress the work (either because you're waiting for someone else or part of the CI!)

I can imagine that it might be very dependant on the nature of work that you're doing, but it definitely sounds like a good practice for a team doing basic feature delivery!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

agile

scrum

forge

sprint-capacity-analysis-app