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; } } }

Story Points

reid.root

Is there a way to hide the story points in the "card view" but keep the data in the "details" section? When resizing stories, teams tend to not put thought into sizing and repeat the sizing that is visible on the card. There is less of a chance that the team will click into the story to see the details.

Accepted answers

Bill Sheboy

Hi @reid.root

Are you using a company-managed or a team-managed project? For company-managed, you may configure card content under board settings. For team-managed, configuring card content is not yet possible, and here is the suggestion to add that feature: https://jira.atlassian.com/browse/JSWCLOUD-17336

You also note "resizing stories". Would you clarify a bit what the team is doing in that area?

One alternative to "resizing" is to not do so, and to discuss variations (forecast to reality) during the retrospective to learn how to improve.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @reid.root

You also note "resizing stories". Would you clarify a bit what the team is doing in that area?

One alternative to "resizing" is to not do so, and to discuss variations (forecast to reality) during the retrospective to learn how to improve.

Kind regards,
Bill

reid.root

Thanks Bill, we're fairly new into sizing stories and I'll look in to see if we're company-managed or team-managed.

For the sizing, we try to have the team size the stories a few sprints out as we go through previous look aheads. Sometimes there is new data relevant to the story, sometimes the team has more time to dig deeper into the story, etc.

Sounds like you have some thoughts in this space?

Bill Sheboy

Thanks for the additional information!

You describe the team using Scrum, correct? If so, during sprint planning you could use a JQL filter (or other method) to determine any planned issues which have been updated since they were refined. Then consider updating the sizing *before* the sprint starts using the new information. That will help reduce the headaches of Jira reporting not matching the facts on the ground from the team.

Kind regards,
Bill

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud