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.

[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.

[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! 

[黄雍蓉]

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.

[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.