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

What do you actually check before field data quality becomes a real problem?

Ben Dangelmayr _Dangel Studio_

Something I keep running into: the field configuration says a field is required, everybody assumes the data is there, and then somebody builds a report on it and the numbers are nonsense.

The two failure modes i see are always the same. Required-on-create teaches people to type something to get past the dialog, so you end up with a due date that is technically filled and completely meaningless. And empty rich text counts as filled in most reports, because a description holding an empty paragraph node is not the same as null.

What i have not figured out is the right moment to look. Waiting until someone complains about a report is too late, but checking by hand every sprint does not survive contact with a real backlog.

Two questions for people running bigger instances than mine:

do you have a routine for this, or is it always reactive?
which fields actually turn out to matter? my guess is due date and assignee carry most of the weight, but that might just be my projects.

Comments

Danno

@Ben Dangelmayr _Dangel Studio_ if you make a field required, the user has to enter a value on create,

A due date is valid data whether or not it is realistic and accurate.

If you have a free-text field, good luck, as your assumption about bad data corrupting reports is valid. I can't even figure out why(or how) you would build a report, dashboard, or any other metric tool using free-text fields.

Assignee might not be a good choice depending on who creates the issue. If it is from an external source, form or CSM ticket, you might not have a default value for assignee to triage the ticket. It could end up in a backlog until that gets planned and assigned.

I have a limited number of required fields in my system and tend to rely more on validation rules and automation to populate needed fields so that they will fit a predetermined filter, etc.

Hope this helps. If you have a specific set of requirements, it might help to publish those here to gather other users' ideas on how they handle it.

Aaron Pavez _ServiceRocket_

Hi @Ben Dangelmayr _Dangel Studio_

Sadly this will fall into the "Train your users" area. You can create all the automation you want, but if you dont have a way to get the real data from, then its difficult.

You could query with JQL all the work items in a certain date or under that sprint and check for invalid data. Which is difficult if you dont know what you are looking for or if you have too many work items.

Tran your people and make them responsible of that data.

Regards

Mykenna Cepek

I prefer to work backwards from the needed data to processes for gathering that data. In other words, first figure out what the true needs are for reporting, then focus on the fields in Jira which supply that data.

Once there is clarity on which Jira fields are important, the team(s) supplying data in those fields need to understand why the data is needed, what reports use that data, what data values are appropriate, and how often to review and update the data. The team needs to own the integrity of their data.

I find it works well to actually show the reports to the team on a regular basis. This "closes the loop" by allowing the team see how their data shows up in the reports.

P.S. Good metrics which resist "gaming the system" is a completely separate topic!

Ben Dangelmayr _Dangel Studio_

Thanks for all the replies! I didn't expect much echo as this is my very first thread. I read all your inputs and I tried to glue them together:

@Danno the validation rule point is the piece i was missing, thanks. Required-on-create asks for the value at the moment where the person knows the least about the ticket. A validator on the transition into In Progress asks when they actually know, and it does not block someone who just wants to file a bug. That is a much better answer to my "when do you look" question than anything periodic.

You are also right about the due date, I phrased that badly. What i meant is that the report built on it is valid too and probably still wrong, which might be even worse, because nobody takes a second look here.

@Aaron Pavez _ServiceRocket_ _ServiceRocket_ agreed on training, and that is the part i keep underestimating. What i have seen fail is training without a visible consequence: people learn the rule in the session and forget it two sprints later... because nothing in their daily view changes when they skip the field

Which is why @Mykenna Cepek 's point about showing the reports to the team regularly is the one completing the picture for me. Training tells people the rule, the recurring report tells them whether anyone noticed.

To answer Danno's question about concrete requirements: the case i keep hitting is not a big instance, it is a handover. Somebody inherits a project and wants to know what they can trust, and the honest answer is "no idea until you look". Validation rules fix everything from that day forward, but the backlog that already exists stays unknown until someone counts it. That is the part i have not solved with process alone.

Danno

@Ben Dangelmayr _Dangel Studio_ , our sympathies regarding inheriting someone elses system/projects. 😣
Glad that helped. As to my comment on using automation, I think you could run a filter for a given project to surface empty fields that need updating with valid information and have it send out an email or Teams/Slack notification to whoever needs to review the ticket to bring it up to date.

Since you're using Jira to set up sprints, is your team fully practicing Agile methodologies, or are you currently focused on learning and applying the Agile principles? It sounds like you have a small development team and I'm guessing you don't have a scrum master to help with getting tickets ready for a sprint. The sprint planning meeting should reject any ticket that isn't complete with all of the information needed to start work on it.

Hugo Mora

@Ben Dangelmayr _Dangel Studio_ — the handover case is the one worth solving separately, because it's the only one process can't fix. Validators protect the future; the existing backlog just needs counting once. A few things that make that count survivable:

Don't audit everything. Pick only the fields that feed a report somebody actually reads, and put a date boundary on it. In practice anything older than two or three quarters isn't worth fixing — declare a trust date, say so out loud, and only measure inside it.

Count, don't list. Run the same JQL twice per field with is EMPTY / is not EMPTY and record the ratio. A fill rate per field per project is a two-hour job and it's the artefact the person inheriting the project actually needs.

For "filled but meaningless", measure plausibility instead of presence. Due dates are easy to probe: how many are still in the past with the item unresolved, and how many cluster on one date (end of quarter is the tell for bulk-set values). If half the due dates land on the same day, the field is decoration and the report built on it should be retired, not repaired.

Your empty-paragraph problem needs the API, not JQL. JQL treats an ADF document containing one empty paragraph as filled. Pull the field via the REST API or a CSV export and filter on content length — that's the only way I've found to see it reliably.

And then the part people skip: fix forward, don't backfill. Bulk-editing old items so the report looks clean just manufactures data that looks as trustworthy as the real thing. Better to publish "this field is reliable from March onward" and let the report start there.

Thanks!

--Hugo

Rasmus Ersmarker

The check I'd add sits next to yours, because it runs on the same evidence: field fill rate.

Two things worth knowing, now the limit is actually enforced. Atlassian's guardrails article lists "Fields per project: 700", but Pavel V (Atlassian) clarified in that thread that "the limit is applied on a field configuration scheme level", and that "Locked and system fields are allowed to go over the limit." Reaching it only blocks new fields: "All work items, and all projects, will continue working same as before." (community.atlassian.com/.../ba-p/3098575)

So fill rate and field headroom are one audit, not two.

One honest gap: I can't find a public API that exposes automation-rule field usage, so a field driven only by a rule looks unused in every report, including mine. If anyone has found one, I'd like the link.

For breadth beyond fields, Optimizer for Jira is a better fit than anything I make.

Disclosure: I build one of the Forge apps in this space, FastAudit , so read this as interested.