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

Does anyone actually fill in Start date on their Jira issues?

黄雍蓉

Genuine question, not rhetorical — I'd like a reality check from people running real projects.

I've been digging into why Jira timeline and Gantt apps so often open up empty, and found something that surprised me. I sampled 400 issues from Atlassian's own public tracker: not one of them had a Start date set. Due date appeared on about 1%.

That seems to explain a lot. Every timeline app reads those two fields. If nobody populates them, the app opens blank, and the app gets blamed. The July 2026 timeline update still requires both dates to be explicitly set, so this doesn't look like it's changing.

So I tried the opposite approach: don't ask anyone to fill anything in, reconstruct the dates from the issue's status change history instead. First transition into an In Progress category = actual start. Transition to Done = actual end. For finished work that isn't an estimate — it's what actually happened.

I measured coverage across six real projects (Apache FLINK/SPARK/KAFKA, MongoDB SERVER/WT, Jenkins). It reconstructs a duration for 23% to 71% of issues depending on the project, median around 55%. The variation tracks how disciplined the team is about moving tickets through In Progress — MongoDB's internal engineering projects scored highest, Apache community projects lowest, since a lot of those issues get filed and never picked up.

Two things I'd genuinely like to hear from you:

1. Does your team fill in Start date? Or is my sample unrepresentative of how companies actually run Jira internally?

2. Would a timeline of what actually happened be useful to you — for retrospectives, status reporting, spotting where things stalled? Or is forward planning the only thing you care about, in which case history doesn't help?

I'm building this, so I'm obviously biased. Very happy to be told it's solving a problem nobody has.

Accepted answers

All comments

Rilwan Ahmed

Hi @黄雍蓉 ,

It depends how and why your teams use Jira. We mainly make use of startdate, end-date fields for the activity tasks like upgrade system, patching activity etc.

Walter Buggenhout

Hi @黄雍蓉,

That is a pretty broad question, to be honest. Very short, if you want to use the timeline properly, start and due date are the fields linked to the boundaries of the bars displayed on the timeline view to represent the duration of tasks.

If you plan work on timelines, updating those fields makes perfect sense. They are required for planning purposes mainly and also to create / visualise dependencies between work items. If a date is missing, creating the dependency simply isn't possible.

For some additional context. Atlassian's public issue tracker is still on Data Center, unless I missed a massive update. In there, the timeline view is not available and so, adding start and due dates to work items does not make a lot of sense. Also, when teams work in sprints (which still happens a lot in software teams), start and due dates are determined by sprint start and end dates and often inherited in other views (such as the delivery timeline in plans).

But while Atlassian back in 2002 really started as a tool for software teams, today more than 50% of teams using Jira are business teams. Those use much more traditional ways of planning where the timeline views are much more common ways of visualising a schedule.

So, all depends a bit on how you work and what teams you want to support. You don't have to use those fields, but if you want to leverage the timeline views voor planning, you more or less automatically do. Note that when you click on the schedule to add a timeline bar to an issue, start and due dates are filled out automatically when the bar gets created.

Hope this helps!

Vladislav Tsaregorodtsev

It depends on where you use it.

From my own experience, if a user is requesting permission for a partner then the Start date should indeed be used as it shows when the permission was granted. The same goes for permissions in general.

The same applies to development. Having both a Start and End date allows you to define when the development starts and when it should be completed. It also helps you get a better overall view of the development timeline.

I also think having a timeline of what actually happened can be useful, especially when you want to look back at how the development went and what took longer than expected.

黄雍蓉

Thank you all — this is exactly the kind of correction I was hoping for.

@Walter Buggenhout — the Data Center point is a direct hit and I need to own it. My sample was Atlassian's own public tracker plus a few open-source instances. Those are precisely the places where those fields have no view attached to them, so I effectively measured "do people fill in timeline fields on instances that have no timeline" and got the answer that question deserves. That undercuts my premise, and I'd rather find that out here than three months from no

Which makes your other point the more interesting one. If more than half of Jira teams are business teams doing traditional scheduling, then they're the ones actually populating start and due dates — and my whole read was built on watching software teams, who get their dates from the sprint instead.

So let me ask the narrower question I should have led with:

For teams that do plan on the timeline — once the work is done, does anyone ever go back and compare what was planned against what actually happened? Not as another field on the issue, but as a view you'd actually open.

@Vladislav Tsaregorodtsev mentioned looking back at "what took longer than expected", which is the specific thing I'm trying to size. Is that a real recurring need in your experience, or does everyone just move on once the ticket close

@Rilwan Ahmed @ — the upgrade and patching case stands out to me, because that kind of work usually has an agreed window and someone eventually asks whether it actually happened inside it. Does your team check the real execution against the planned window afterwards, or is closing the ticket the end of it

Walter Buggenhout

On the what was done vs what was planned topic: yes, there are teams doing this. That is just an observation from customers we work with and that do this type of planning, mostly in traditional project environments.

At those customers we usually see traditional Gantt chart implementations on top of Jira, as those add baselines to chart. This is not natively a feature of Jira and - if you ask me - understandably so.

With 15 years of experience in agile environments, for me personally looking back at how accurate your plan was, does not add a lot of value. We know - even up front - that a plan will need to be adjusted along the way most likely 100% of the time, so personally, I like to focus my efforts in adjusting things looking forward. But again, I can assure you that these comparisons are being made in many organisations (and - most likely - with good reasons).

黄雍蓉

@Walter Buggenhout — that's extremely useful, thank you. The baseline point in particular; I'd been describing this as "planned vs actual" and clearly the people who buy it call it something else.

One last thing, then I'll stop taking your time. At those traditional-environment customers, the baseline only works if someone actually captured one — a plan with real dates, snapshotted at the right moment. In your experience, how often is that actually in place? I'm trying to work out whether the gap is "no tool for this" (clearly not, you've corrected me) or "tool exists, but the discipline it assumes often isn't there."

If it's the latter, reconstructing what happened from the issue history would at least work retroactively with no setup. If it's not, then this idea doesn't have a job and I should hear that.

Ben Dangelmayr _Dangel Studio_

I build a small free app in exactly this corner (Field Health, it scores field completeness per project, so you know where I stand, this is my own product: https://marketplace.atlassian.com/apps/46032572/), and this thread is the most useful reality check i have seen in a while. Thanks for actually counting instead of guessing.

The pattern your numbers suggest matches the assumption my app is built on: fields get filled when something visible depends on them, and only then. Due date has boards, filters and reminders pulling on it. Start date has basically nothing a team opens daily, so it starves. Walter's observation about business teams fits the same rule, they look at the timeline view, so the timeline fields get fed.

One design lesson from the enforcement side: required-on-create tends to teach people garbage values, a date gets typed to pass the dialog and is never touched again. That is why I went with measuring instead of enforcing, a per field completeness score plus a worst first fix queue naming what is missing per issue. Whether that moves Start date coverage at scale i cannot claim yet, the app is young. But it makes the rot visibl instead of pretending a required flag fixed it.

Your status history reconstruction is a genuinely nice complement, actuals without asking anyone to type anything. And the 23 to 71 percent coverage spread reads plausible to me, it tracks how unevenly teams move tickets through In Progress, which is its own hygiene problem one level down.

黄雍蓉

@Ben Dangelmayr _Dangel Studio_ — that framing is better than mine and I'm going to steal it. "Fields get filled when something visible depends on them, and only then" explains my data and Walter's correction at the same time, without either of us having to be wrong. Start date starves because nothing opens on it daily. That's the whole thing in one sentence

On your caveat — you're right that status hygiene is the same rot one level down, and I should have flagged it. What I can offer is that it degrades more gracefully than the date fields do. Across the six projects I measured, the worst (Apache Flink, lots of filed-and-never-touched issues) still reconstructed 23%, and MongoDB's internal engineering projects hit 71%. People move tickets because that's how they signal to each other; typing a date signals to nobody. So the correlation is real but the floor is a lot higher than zero.

The question I'd actually value your view on, as someone who has shipped into this Marketplace and I haven't:

Is reconstructed actuals a product, or a feature of something else? You called it a complement, and I suspect you chose that word deliberately. My honest read of this thread so far is that the traditional-planning crowd Walter describes already gets this via baselines in the big Gantt apps, and the agile crowd doesn't want it at all. Which would leave it as a nice capability with no one specifically shopping for it.

If that's how it looks from where you sit, I'd rather hear it now.

Ben Dangelmayr _Dangel Studio_

Honest answer, from one shipped free app: standalone i think it is a feature, not a product. Nobody types "reconstructed actuals" into the marketplace search box. A capability without its own search phrase has no acquisition channel, and even with a phrase people do type, discovery at zero reviews is brutal, i can tell you that much from the last weeks. So take my judgement with some salt, my app is freshly released, time will tell if the measuring approach earns its keep either.

Two exceptions i would test before believing me. Rilwans case is audit, not planning. An agreed window plus "did it happen inside it", that gets shopped for standalone, with budget attached. Narrower, uglier, more real.

And the version i would actually want after this thread: write the reconstructed dates back into Start and Due, optional and clearly marked as reconstructed. Then its not another view, its a fix for the empty fields you counted at the top, and every existing timeline app suddenly has data. You would be feeding the gantt apps instead of competing against them.

黄雍蓉

@Ben Dangelmayr _Dangel Studio_ — "a capability without its own search phrase has no acquisition channel" is the most useful sentence anyone has given me in weeks, and I think it just paid off.

You told me to test the two exceptions before believing you. I went looking, and found a third one hiding behind Walter's word.

JRACLOUD-88013, "baseline a plan against target dates": 322 votes, 156 watchers, 55 comments, open since 2020, still Gathering Interest. Highest-voted planning request I've come across in the tracker. And unlike "reconstructed actuals", "baseline" is a word people type.

The interesting part is what they're actually complaining about. Baseline features do exist — BigPicture Enterprise, Structure. But from the comment thread:

"changes continue to occur after the initial planning phase, causing us to lose the established baseline."

So the failure mode isn't a missing feature, it's a missing snapshot. Every existing baseline tool needs someone to freeze the plan at the right moment, and that's the same discipline problem you described with required-on-create fields — it depends on a human doing something at a specific time, so it rots.

But the changelog records every change to the date fields. The original plan was never actually lost. You can reconstruct what the dates were on any past date, retroactively, with no snapshot and no setup. It's the same technique I was applying to status transitions, pointed at a different field and a phrase people search for.

Two honest caveats before you answer: baseline comparison is periodic, not daily, so retention is a real question. And Structure sits at 4.55 stars — this isn't a category where incumbents are doing a bad job.

Does the retroactive angle change your read, or is this still a feature looking for a product? You were right the first time and I'd rather you be right again than be polite.

Shirley Jones

Having spent a long time in project world, I have a unique insight on how project delivery works inside and outside Jira. Outside Jira, start and due dates are critical to knowing when things are being done, it's a basic timeline tracking often done in isolation MSProject, Excel, MS Planner etc - even with Jira as the mandated inhouse tool for transparency.

Our PMO uses Jira for project work (mainly non-IT), and the start/due date is valuable for milestones and building Gantts in Structure. As we're getting better understanding of our resourcing needs, start/end/due dates are useful for us to get a feel for when resources are required and for how long.

So, from a pure project lens, start and end/due dates are invaluable to track work and milestone slippages, and also to track when dependency critical dates exist.

黄雍蓉

@Shirley Jones @ — this is the perspective I was missing. Most of what I'd gathered came from software teams, and you're describing the world @Walter Buggenhout pointed me at: PMO, mainly non-IT, dates genuinely load-be

The phrase I keep coming back to is "track milestone slippages", because slippage is a comparison — it only means something against what the date used to be.

So: where does the "used to be" live for you?

Structure lets you take a baseline, but that assumes someone froze the plan at the right moment. There's a request in the Jira tracker for this on the Plans side (JRACLOUD-88013, 322 votes, open since 2020) and the recurring complaint in the comments isn't that baselines don't exist — it's this:

"changes continue to occur after the initial planning phase, causing us to lose the established baseline."

Which makes me wonder whether the problem is the snapshot rather than the tool.

Two things I'd genuinely like to know from someone actually running a PMO:
1. When a milestone slips and someone asks "what did we originally commit to" — can you answer it from Jira, or does that answer live in the MS Project file / a slide from the kickoff / someone's memory?
2. You mentioned planning often happens in MSProject or Excel even where Jira is the mandated tool. If the real plan lives outside Jira, does the Jira-side history matter at all for slippage tracking, or is Jira just the execution surface?

The second question is the one that could sink what I've been building, so I'd rather ask it than avoid it.

Shirley Jones

Nice tough questions, and I'm glad y answer helped.

There's two ways of tracking milestone changes (possibly three, but I need to think about the third);

Create a JQL/Automation that emails you daily with changed dates on milestones. For us, I built a Milestone worktype for our PMO so we could track then separately. so the JQL might look like Worktype = milestone and duedate changed and status category~=done, with the automation trigger being work item updated. then action being to email you when this occurs.
This will tell you a change has occurred, but not necessarily the original date (I looked at the history logs to confirm).
In Structure, do baseline updates weekly to capture those changes.

Both these might benefit from an additional automation updating a custom field. We have one called "original Due Date" which is populated to demonstrate slippage and stays there until formal project change approves the new milestone dates.

Sounds like there needs to be some formal project governance controls around milestone date changes. Could be as simple as having a register in SharePoint (as a list), Confluence or even XL, linked into the Milestone to capture there's a date change and it needs approval by sponsors etc.

Re non-Jira systems being used, it's all about building a Jira they want to use and makes sense. People still use other sources, but we ask they keep the reportable data in Jira so we have transparency.

黄雍蓉

@Shirley Jones — this is the most useful answer I've had, and one sentence in it stopped me:

"This will tell you a change has occurred, but not necessarily the original date (I looked at the history logs to confirm)."

That's the exact gap. Your automation catches that something moved. Structure's weekly baseline catches roughly where it was. The "original Due Date" custom field holds it, but only from the moment someone set it up, and only until the next approved change. And when none of those quite answer it, you go and read the history log by hand.

Which is the thing I've been building — except the changelog already holds every date every milestone ever had, so it can be read out automatically instead of manually. No baseline to remember to take, no custom field to backfill, and it works on milestones that slipped last year as well as ones that slip next week. For a given milestone: what was it originally, how many times has it moved, by how much each time, who moved it, and when.

Two questions, and please be blunt on the second one:

1. If that existed, would it replace any of your three mechanisms, or would it just sit alongside them as another thing to look at? I'd rather build something that removes work than adds a tab.

2. You said governance around date changes is what's really needed — a register, sponsor approval. Is that the bigger problem? Knowing the original date is a reporting question; controlling who's allowed to change it is a process question, and those are different products. From where you sit, which one actually hurts more?

And if it's useful, I have a rough version running that reads dates back out of the changelog. Happy to point it at a throwaway project and show you what it produces — no pitch, I'd just rather get told it's wrong by someone who runs a PMO than find out later.
1. If that existed, would it replace any of your three mechanisms, or would it just sit alongside them as another thing to look at? I'd rather build something that removes work than adds a tab.

2. You said governance around date changes is what's really needed — a register, sponsor approval. Is that the bigger problem? Knowing the original date is a reporting question; controlling who's allowed to change it is a process question, and those are different products. From where you sit, which one actually hurts more?

And if it's useful, I have a rough version running that reads dates back out of the changelog. Happy to point it at a throwaway project and show you what it produces — no pitch, I'd just rather get told it's wrong by someone who runs a PMO than find out later.

Vahtang Manukyan - Be On Time

Hi,

This thread has surfaced the real gap better than most feature requests have. The recurring complaint — "changes continue to occur after the initial planning phase, causing us to lose the established baseline" — is a discipline problem, not a missing field, and it's the same reason Start date starves: the value of a snapshot is only visible the day someone asks "what did we originally commit to?"

Disclosure: I'm on the team behind MSP Planner for Jira, so read the rest through that lens. The question Shirley raises is exactly what the baseline feature exists for:

You capture a baseline at the moment of stakeholder approval — a snapshot of start/finish/effort for the whole schedule.
- The baseline then renders as thin "ghost bars" under your live tasks, so drift in either direction is visible at a glance without touching the working plan.
- When a change request is approved, you materialize the new baseline — so reporting stops drifting against a plan that is no longer valid.
- And if the real plan lives in MS Project (common for non-IT PMOs), you can import it 1:1 into Jira — identity is preserved and changes are reviewed before they write back to issues — then baseline inside Jira, so "what did we commit to" lives next to the work instead of in a file or a slide.

There's also a three-point comparison: baseline vs plan (was the estimate optimistic?), plan vs actuals (is execution lagging?), baseline vs actuals (total drift). That split between planning failure and execution failure is the one steering committees actually read.

Marketplace page: https://marketplace.atlassian.com/apps/3162894022/msp-planner-for-jira

And the status-history reconstruction is a genuinely nice complement to all of this — it recovers what happened, while a baseline preserves what was promised. Different questions, both worth answering.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud