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

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

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.

It is, @黄雍蓉. Classic examples are construction or infrastructure projects with lots of things to be done, several milestones (not rarely also bound to billing milestones) and time-bound deliverables.

Traditionally, such projects are managed by a project manager and work is - in many cases - not tracked in real time by the people doing it in the field. I guess in many cases the delay on progress reporting makes the view of the initial plan more relevant. In this - somewhat disconnected - world the plan IS the periodically updated version of reality and then being able to see the initial baseline helps identify risks and delays. 

@Walter Buggenhout  — your baseline pointer led somewhere, so thank you for it.

 I went and looked in the Jira tracker. JRACLOUD-88013, "baseline a plan against target dates": 322 votes, 156 watchers, 55 comments, open since 2020, still Gathering Interest. It's also a regression — the description says old Portfolio had this and Advanced Roadmaps dropped it.

 What struck me reading the comments is that the complaint isn't quite "there's no baseline feature". BigPicture Enterprise and Structure both have one, as you said. The complaint is this, from one of the more recent comments:

 "since it is a live view, changes continue to occur after the initial planning phase, causing us to lose the established baseline. This makes it difficult to retrospectively review and identify reasons why the plan was not fully executed."

 That's a different failure. The tooling exists, but it assumes someone froze the plan at the right moment, and in practice nobody does.

 Which connects back to what you said about those construction and infrastructure customers — where the plan is the periodically updated version of reality. If the plan keeps getting updated and no snapshot was taken, the original commitment quietly disappears.

 So the question I'd value your read on:

 At those customers, when someone asks "what did we originally commit to" — six months in, at a steering committee, in a delay discussion — how often can they actually answer it?

 If they always can, then this is a solved problem and I'll stop. If they often can't, that's a specific gap, and it's one that could be filled from the changelog rather than from discipline.

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

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.

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

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.