How to categorise items as fillers/low hanging fruit

[Anita Bennett]

We are using a combination of the following fields to give a sense of the nature and complexity of changes.  

• component (standard field)
• theme (custom field)
• estimate (standard field)
• t-shirt size (custom field)

What we are then looking for is something to identify the low hanging fruit .. the low complexity and small items that sit within a component and theme.  We will want to be able to report on them.  Do you have any suggestions?  I am not keen on a label as those cannot get used on kanban, right?  That suggests a field but with one item in the drop-down of "candidate for filler".  Is there another option?

[Monika Ambrozowicz_Seibert_]

Hi @Anita Bennett, for flagging issues as 'low hanging fruit' or filler candidates, you have a few native Jira options worth considering before reaching for a Marketplace app.

A single-select custom field with one option (for example, 'Candidate for filler') works exactly as you described. It is reportable via JQL and filters, and it shows up on boards. You could also use a checkbox field type (native Jira supports this) which gives you a simple ticked/unticked state per issue. On the label concern: you're right that labels have limitations on kanban boards, but a custom select or checkbox field doesn't share those constraints.

If you want something more visually distinct - so that the flag is immediately obvious when scanning a board or issue list - a Marketplace app like Awesome Custom Fields is worth checking out. Full disclosure: I am affiliated with the team behind the app. 

It includes a Simple Toggle field type, which is a clean boolean on/off switch that appears directly on the issue view. Since you're already using t-shirt size fields, it's worth noting that Awesome Custom Fields has a dedicated T-shirt size field type as well, available as a part of the entire package of custom fields. It means you could consolidate some of your custom fields under one app. It also includes Color Labels, which give issues a colored visual tag rather than the default grey Jira labels, handy if you want 'filler' items to stand out at a glance on a board.

Both the Toggle and Color Labels are reportable via JQL, so your reporting requirement would be covered.

If the native checkbox or single-select route works for your team, that's honestly the simplest path. But if you want the visual differentiation on the board, the Toggle or Color Labels fields in ACF give you that extra layer. You can try it for yourself for free.  

[Paul Glantschnig _Appfire_]

Hello @Anita Bennett,

A single-select field does work, but it's one more thing someone has to remember to set. Since your definition of a filler already lives in the fields you have (t-shirt size, estimate, component, theme), another option is to derive the flag instead of storing it.

If you're open to an app from the Atlassian Marketplace, JXL for Jira lets you add a formula column for this, e.g. IF(this.tShirtSize?.value == "S", "Filler candidate", ""), and you can combine the estimate or anything else into the condition (field names come from the editor's autocomplete). Unlike the native formula field, it isn't limited to numbers or team-managed projects.

From there: group the sheet by component or theme, filter down to the candidates, add conditional formatting so they jump out, and save it as a view for the team. Nothing to keep filled in, so the list never goes stale.

Disclosure: I work for the team that builds JXL.

Cheers, Paul

[zoltanersek _outpostlabs_dev_]

If you want to report on it consistently, I would use a dedicated single-select custom field rather than labels. It's more structured, you could even populate it automatically with a jira automation. 

[Marc -Devoteam-]

Hi @Anita Bennett 

You could look at the option to use a Formula field.

https://support.atlassian.com/jira-cloud-administration/docs/create-a-formula-field/ 

[Davit Mkrtchyan - Be On Time]

Hi @Anita Bennett Anita -

It is a great idea to identify those "quick wins". Having a set of low-complexity tasks is a lifesaver for a team when they are waiting for a review or have a small gap between larger items.

Regarding the technical side: labels actually do work on Kanban boards, but you are right to be hesitant. Labels are prone to typos (e.g., "QuickWin" vs "quick-win"), which makes your reporting a nightmare. For reporting, a custom dropdown field (Select List) is definitely the way to go. It ensures data cleanlines and makes your JQL filters reliable.

However, I would like to offer a word of caution from a governance perspective.

There is a common trap called the "Productivity Illusion". It happens when a team starts prioritizing "low hanging fruit" because it feels great to close ten small tickets in a day. The board looks active, the velocity seems high, but the critical, complex tasks - the ones that actually drive the project finish date - remain stuck.

The danger is that "fillers" can easily become a distraction from the critical path.

My suggestion: do not just categorize these items, but limit them. Instead of letting "low hanging fruit" compete for priority with your main goals, treat them as a capacity budget. For example, decide that only 10 percent of the sprint bandwidth can be spent on fillers.

This way, you keep the momentum and the "quick win" feeling, but you ensure that the team's primary energy is spent on the hard, high-value work.

Hope this helps you set up a system that is both easy to report and safe for your delivery!