Introducing manual board clearing for your next-gen Kanban board!

[#1]

Hi Atlassian Community!

My name is Ivan, and I’m a Product Manager on Jira Software Cloud.

Project admins are spending hours a week tracking their team’s work on their boards. End users use the board to update their work and need to visit it frequently.

We’ve heard from many of our users that having too many completed issues causes more clutter and increased their board’s load time, slowing their team’s agility.

In our continued effort to increase the performance and scale of next-gen projects, as well as provide admins with an easy and flexible customization option, we are launching the ability to clear Done issues at any time with manual board clearing.

Not only will this prevent completed issues from piling up on the board, it also allows next-gen boards to load and perform faster overall.

• For project admins, you’ll have control over when completed issues disappear from your board.

• For teams, you’ll be able to focus on the work that matters most to your team.

How manual board clearing works in next-gen projects

Manual board clearing will be an exclusive feature for next-gen projects. This is for next-gen Kanban (sprint-disabled) projects, and you'll need to be an admin to use it.

We believe that giving you more control over when you clear issues will result in a more effective and high-performing team.

Clearing completed issues is a way of cleaning your board of work that is considered dev-complete, providing the focus required to optimise your team’s Kanban flow.

• We decoupled board clearing from Releases/Versions, unlike in classic where they are coupled together, as the problems that they are trying to solve are different.

• Clearing these issues will also clear them from the board container in the backlog view, but not the Roadmap as the Roadmap tracks work at a level higher than the board.

• You can access cleared issues at any time by enabling the next-gen project issue navigator.

• You can also click the “See all Done issues” link in your board’s DONE column. If you’re using the GROUP BY swimlanes on the board, this link will appear under the “Unassigned” / “Issues without Epic” / “Issues without Subtask” swimlane.

FAQ

Can I clear a parent issue in the DONE column with incomplete subtasks, and vice-versa?

You can clear parent issues as long as they are in the DONE column.

Subtasks are not at the same level in terms of issue hierarchy, so we are only enabling clearing based on a status check on parent issues.

• If the parent issue is done, it will be cleared regardless of the status of its subtasks.

• Clearing is possible in any GROUP BY view (None, Epic, Assignee) that shows parent issues. It is not available when using the GROUP BY SUBTASKS view, as shown below.

Ideally, a piece of work should represent itself end-to-end, as the work is only truly done when all its subtasks are completed. However, we didn’t want to force this principle upon all our users since different teams may work in different ways.

• You can still choose to enforce automatic closing/not closing of subtasks or parent through Automation for Jira in project settings.

How should I use manual board clearing alongside Releases/Versions?

In classic, we tied the ability to manually clear DONE issues together with Releases. This has resulted in scenarios where teams who aren’t doing continuous releases (e.g. quarterly releases) end up waiting many months to clear their boards, resulting in their boards becoming very slow and cluttered.

We have decoupled this from Releases in next-gen, so that you won’t end up with this problem.

• Focus your team on work that has finished development in the board view, and clear your board of completed work at any time to maintain your board’s hygiene and keep it tidy.

• Track a release date to customers for a collection of cleared issues through enabling Releases and tracking them in another view.

• A release is switching on a feature flag and should ideally not take up your team’s focus on the board.

Why can’t I clear individual issues?

Shipping issue-level clearing may result in a state where issues are cleared individually by different people, and the rest of the team has no visibility into what happened.

We recommend clearing issues together during team meetings, so that the product owner has agreed with the team on the definition of done (e.g. automated tests, QA, analytics, approved Pull Requests, green builds, merged) before they’re cleared.

• If there is an issue that shouldn’t be cleared, it might be best to represent it in another column.

How do I get the issue back on the board?

Completed issues should ideally not be brought back on the board, so it is best to create a new issue to reflect the latest thinking about that piece of work.

• If you do want to restore a cleared issue, you can do this via a status change of the issue.

How does automatic clearing work alongside manual clearing?

The 14-day automatic clearing rule is based on when you resolve an issue, which is currently tied to the DONE column. Manual clearing allows you to clear DONE issues at any time you prefer.

The configuration of the automatic clearing rule is dependent on board settings being shipped first. You can track the progress of board settings here.

In the interim, manual clearing should resolve most of the pain you’ve experienced with completed work.

Is clearing an issue the same as archiving an issue?

Issue “clearing” is a concept we’ve introduced that best reflects the solution to our users' problems. Clearing an issue effectively hides it from the board/backlog. You will still be able to search and view cleared issues using the global and project issue navigator.

• Issue archiving, which hides it from the system search and places it into an archive is something that is not being looked at for the moment.

I’ve got suggestions or questions – how can I provide feedback?

• Provide feedback using the “Give feedback” link in the bottom left of your project navigation.

• Feel free to reach out to our support team if you have any suggestions.

• Learn more about using this feature in our support documentation.

[mararn1618 _secretbakery_io_]

Yes, thanks Ivan! :)

[brian.desany]

Is there a reason that this is not available on sprint-enabled boards?

[Ivan Teong]

@brian.desany Scrum teams that work in sprints have a fixed scope between a time period, so that is why completed issues should remain on the board to provide clarity for the team about the progress of work in the sprint's scope, when reviewing the board together during standups and team meetings.

Morever, when you close a sprint, the completed issues will clear.

This doesn't happen with Kanban teams that don't work in sprints, as Kanban teams are more about optimising the flow of issues on the board that can be done at any time, rather than looking at a fixed scope during a fixed time.

[Geert de Vries]

@Ivan TeongI would like to give the product owner the 'right' to give this feature (clearing done) but in our case the PO doesn't have the admin rights, they have their own role with a subset off rights from the admin role (copied from the admin role, but some restrictions) for now the menu does not appears at hover over the 'done' column is it only working with the build in 'admin' role or am I missing some?

[Ivan Teong]

@Geert de Vries The ability to clear is only for users with edit board permissions, which in this case is either a Jira admin or next-gen project admin.

• If you're on the Free plan, then the ability to clear is tied to Jira admin rights, which is managed from the global settings cog.
• If you're on the Standard/Premium plan, then the ability to clear will be tied to the "Administer (project)" permission - Edit access, manage people and permissions, configure issue types and their fields, enable project features, and delete the project.
  • The above is the first granular permission you see when you're in the modal for creating a custom role with more granular permissions.
• You can read more about permissions here: https://support.atlassian.com/jira-software-cloud/docs/next-gen-permissions/

[Geert de Vries]

@Ivan Teong Yes i did found out meanwhile that the ability to clear is bounded to the 'edit board' permission, but unfortunately i do not like the idea to give our product owners and scrum masters the right to edit the bord, since we are no software development company our product owners are (hope they do not read this ;-) ) more or less 'digibeten' as we say in dutch (useless with computers). Before i changed the subset of rolle's some of them already managed to delete one complete issue type from a board heavenly used in the last few months :-(

Any change the 'one setting' in the roles for project permission is splitted in some more 'individual' rights?

Regards,

Geert

[Ivan Teong]

@Geert de Vries I understand where you're coming from, but we won't be revisiting the edit board permissions anytime soon.

In terms of the problem you face with your product owners, I recommend going through a framework for decision-making with them, instead of removing their permissions which might signal to them a lack of trust (which can potentially result in team morale issues in the long term).

The product owners and scrum masters are the ones that interact with their teams daily and will be more in-tune with their team's problems and workflows. By empowering them with the autonomy to decide what is the best way to set up their team (and project) for success, it will allow them to move at a higher velocity to solve problems in the most optimal way.

Autonomy and control is a fine balance, and veering one extreme or another is usually not ideal. What we do within Atlassian or advocate for agile teams is to adapt frameworks to help with decision-making. You can use the decision tree and DACI models to help facilitate the conversation with the team:

• Decision tree model (by Susan Scott) example: https://blog.seibert-media.com/2019/01/03/the-decision-tree-model-making-decisions-with-a-current-development-project-as-an-example/
• DACI framework (available in Confluence as a template): https://www.atlassian.com/blog/inside-atlassian/make-team-decisions-without-killing-momentum

Although your company isn't a software company, but I believe that you would like your team to move with agility! If you want to read more about the Agile manifesto (that still holds true today), you can read up on it at: https://agilemanifesto.org/principles.html

[Yim SeMin]

Hi. I was looking for this feature and I'm glad to hear that it updated just in time.

However, I cannot use the function.
I did the following, is there anything else I need to check?

- Our team uses the Free Plan.
- Project is Next-generation, and Sprint is disabled.
- In the Next-generation project setting, I come out as Administrator, I can't modify it.
- In Global Setting , I gave me as much authority as possible. (Like site-admins group, administrators Group)

[Ivan Teong]

@Yim SeMin The option to clear only appears in the meatball menu if there is at least 1 issue in the DONE column. Otherwise, check whether your DONE column is the right one - it should have a green tick at the top of the column (indicating this column maps to the DONE status category) beside the column name. Let me know if it works based on either of the above.

[Yim SeMin]

@Ivan Teong Thanks a lot! Now I can clear issue.

By the way, I've found something strange. (Problem is solved)

In my project, there is 7 issues on Done column but menu says that I can only clear 1 issue(Red Box).

issue 'Now-5' was created and completed in the current project.

Others(issue 'Now-43', ...) were created and completed in different Next-gen projects. After completion, it was moved to this project.

If I click "Clear issue", then only 'Now-5' issue disappear.

Solution: Change the status of the issue to a different state and then return it to completion, then I can clear it

[Andrew Taylor]

cloud version unusable for next gen projects .... too slow 

[Deleted user]

Hello All,

For some reason we don't see the option to clear issues. My questions are following:

• Is this exclusively for the issues that were created with a Kanban template
• Is the feature available for projects created via Scrum template
• Do we need to recreate our project to be able to use the feature?

[Nick Bishop]

This really should be also be available for Sprints...we sometime do long (2 month) Sprints and can have hundreds of issues and make our Jira boards very slow...why can't you give us the ability to clear issues. Crazy

[Ivan Teong]

Hi @[deleted]

You can use manual board clearing with any sprint-disabled next-gen projects.

The differentiator with next-gen is that you don't need to stick with the Scrum or Kanban template you created, you can switch between agile methodologies at any time through the feature toggle in your project settings page:

If you're disabling sprints, the issues that was in your active sprint container will go into your board container in the backlog view. This board container will be one that syncs with the issues appearing in your board view.

Those in the inactive sprint container will go into your backlog container.

BEFORE DISABLING SPRINTS:

AFTER DISABLING SPRINTS:

If you disable the backlog as well, the backlog view will be disabled and all these issues in the backlog will be moved fully to your board view.

From the above, you'll know what you want to appear on the board and use manual board clearing accordingly.

However, I'd advise you to still utilise the backlog even if your team is not doing sprints, which is what we call the Kanplan (Kanban with backlog) agile methodology, as this will allow your team to focus sharply on the highest priority items on the board view, while you use the backlog view to groom the priorities of what should go into the board view (through the board container).

Hope that helps!

Regards,

Ivan Teong

Product Manager, Jira Software

[Ivan Teong]

Hi @Nick Bishop

I'm curious to know how come your sprints are 2 months long. Sprints are usually a short, time-boxed period with a fixed scope as mentioned here: https://www.atlassian.com/agile/scrum/sprints

2 months is really long for a team, and it might impact your team's morale as it will feel less like a sprint and more like a marathon.

Are your sprints long because the scope is too wide, or the work has not been broken down to manageable pieces? Or is it because you have a really big team working on the board?

Regards,

Ivan Teong

Product Manager, Jira Software

[Nick Bishop]

Hi Ivan

Thanks for your reply. I know thats the "real" definition of Sprints and we may not be doing Sprints "Properly" but thats just how we find it works for us...it seems Atlassian assuming everyone is using things "perfectly" is not very flexible for teams to work out what suits them best. Why not just have the feature available for those using Sprints? Seems very arbitrary...

[Deleted user]

Hello @Ivan Teong , Thank you very much for your reply. I was looking through the comments in this thread closer and found the solution that I was looking for.

I guess in our board the done column was not mapped in the workflow correctly. 

[Deleted user]

We also have sprints enabled on our board... however we don't actually work in sprints.  We work as a regular Kanban (continuous work, continuous release) team.  We enabled sprints in JIRA solely in order to have multiple backlogs for the team to pull work from to add to the board during replenishment meetings.

For example:

- One backlog (a renamed future sprint) contains all issues that come from Support (bugs, feature requests, etc.).

- Another backlog (another renamed future sprint) contains Technical Debt items that the team has identified.

- The regular backlog contains new initiatives, features and addons that come from Product.

Each time we meet to replenish the active board with items from the backlog, we pull a percentage from each one.

--

We would love to be able to clear "done" items on the active board, without having to do extra legwork to close out the current sprint... find all items that were still open on the board, add them to a new sprint, and start the new one. (Also a pain because we have to rename the "Work-in-Progress" sprint each time.)

[Ivan Teong]

Hi @Nick Bishop

The official recommendation by Scrum.org for sprint durations is a maximum of 1 month: https://www.scrumguides.org/scrum-guide.html

"The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created."

I've seen teams working from 1 to 3 week long sprints.

• I would say that 2 month long sprints is likely a minority (my guess is that this might be more for teams that do waterfall rather than agile), which will result in other issues like slow boards or engineers feeling like their progress of work is slow, which in turn affects their morale.

If you want to chat more, I can arrange an in-person chat with you to find out more about how your team works, as my team is currently looking in the problem space of performance for next-gen.

• I've sent you an email outside of this community post.

Why shorter sprints?

• Learn: Since the team has more but shorter team retrospectives (https://www.atlassian.com/team-playbook/plays/retrospective), they have more opportunities to try smaller changes. This also provides more opportunities to learn and drive the team into a more optimal way of working.
• Iterate: More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to change. This should largely eliminate the need for the Product Owner to ever ask for a change (i.e. new Story) in the current Sprint.
  • Scope changes when the sprint has started is an anti-pattern and should be avoided.
  • If using sprint burndown chart report, your scope change log section should be empty.
• Unblock: Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.
• Focus: Shorter cycles make planning easier, which increases focus and reduces the amount of “dark work”. This increases visibility and gives the Product Owner better control over prioritization and deprioritization.
  • Sprint goals should be concise and not too broad such that it isn't achievable.
• Breakdown: Forces teams to do a better of job of slicing Stories or Features into smaller chunks, so whatever is in the sprint can be finished (meaning dev-work complete, NOT as part of a monthly release).

I feel like the complexity of the current sprints could very well dictate their length. If you're at the phase of the project where you're just resolving minor bugs, then maybe smaller sprints are easier. However, if you're making major changes to the system that require a lot of focus by the development team, then longer sprints may be more appropriate.

Finally, consider that if the sprints need to be longer than 30 days, you may need to check with the development team and ask them if they're designing the system with agile best practices in mind. Many techniques that are popular today, such as using a RESTful architecture, allow for independent deployments of modular components, which helps prevent bugs in other systems and create an environment where deployments can in fact be made more frequently.

[Nick Bishop]

Thanks Ivan I have responded to your private message.

In the end we are a very small team producing Desktop software in a more traditional fixed release manner so I expect slightly different to most cases, as you say, we are likely a minority case but just having ability to clear columns would have been helpful.

Thanks for your time.

Nick

[Ben Golder]

Just commenting since I see this hasn't been touched on yet by the mods: how come we aren't able to fully clear out the done column?

I've got boards with 40+ issues in the done column, however it will only max out at doing 20 issues... once in a while. Is there something I'm likely missing?

Sprints are off, no backlog, no on-call schedule, etc. Just kanban and the visualizations plus some filter views.

[Ivan Teong]

@Ben Golder Are all the issues resolved? A resolved issue has a green tick on its card beside the avatar as screenshot below:

It only clears resolved issues. Sometimes, issues in the DONE column isn't resolved as it was moved to a DONE column that was previously not a resolved column (when users move columns around or delete the DONE column).

The DONE column should be mapping to a DONE status category (what we call the resolved state). Notice the green tick beside the number of issues in the column which represents that.

Let me know if that is the case why issues aren't clearing. Board clearing only clears resolved issues.

[Ben Golder]

Interesting - i know the column indicates it's official with a green checkmark, but i've never seen one on any of the issues within that column. 

I think all of the outstanding issues in that column are ones which were in that column before it became the official DONE column.

Do you know of a way to safely update all of those issues so that they can be cleared out without triggering any automations which would be linked to issue status?

[Ivan Teong]

@Ben Golder Currently, if the issue is resolved then it should have the green checkmark.

From your description, it seems like you've moved the column which was previously not the resolved column to become the new resolved column right? If that is the case, then:

• issues that were in the previously-unresolved/currently-resolved column will stay unresolved
• new issues created in this column will be resolved (and clear-able).

If the above is right, I think the way to update the issues will be manually moving the issue out and back into the column which will resolve them in the process (and checking if the automation rule triggered will be problematic).

Let me know if that works.

[Nate Embree]

When I went to clear my board, I only had 26 to clear. There are still 221 in the column. Why is that?