Existing original time estimates show 0 in backlog until issue is opened

[Kent Pilkington]

Disclaimer: This is my first time using Jira, and I'm trying to use it to estimate a website project. I have some familiarity with Agile, though not from any particular dogma.

I've created a couple of epics, one for backend stuff and one for frontend stuff. I'm adding a bunch of tasks to my backlog under each, and I'm trying to make sure that I've estimated time for each one. 

If I reload the page, none of the tasks (estimated or not) show anything for the estimated time.

If I mouse over the task, it shows 0m.

If I click on the task and the task has been estimated, the backlog is updated with the estimate.

If I click on the task and the task has not been estimated, nothing changes (which makes sense).

So, in order to see if I have estimated everything, I have to go to each item one by one and inspect it so the backlog updates.

Also (and I can put this in a separate issue if necessary), if there are any estimated sub-tasks, the task estimate remains 0. I haven't found a workaround for this one.

[Kent Pilkington]

I'm also unable to replicate the estimate roll-up behavior that I experienced earlier. Odd.

Regarding sub-task estimates, I don't think we're talking about the same thing. I haven't yet figured out how to add stories and work them into sprints. 

I am able to add tasks, though. Tasks have a field for Original Estimate. Tasks can also have sub-tasks. Each sub-task also has a field for Original Estimate. I need to estimate the time/effort that it might take to complete the task. I do that by breaking down the task into the sub-tasks, estimating the effort, and then rolling them up. Granted, the estimate will be on the low side because we almost never account for everything, but that's life.

So, how do I get sub-task estimates to roll up to task estimates? Getting the task into a story/sprint is also a good question, but not my immediate challenge.

[Nic Brough -Adaptavist-]

Sub-task time estimates do roll up into issues, when you view an issue the estimate section has a tick-box to toggle "include subtasks" in the time panel, and the issue navigator lets you display a set of Σ fields that add up all the values in a sub-task on to the issue of which they are a part (Σoriginal estimate, for example)

But you can not use these as a sprint estimate - sub-tasks are not sprint items; Jira takes the simplest approach and ignores sub-task estimates for sprints.

[Kent Pilkington]

I think there's something I'm totally missing here. 

Nobody says, "I have capacity for some of that task in this sprint, but I'm not going to add that sub-task because i can't add the whole task". That wouldn't make sense.

And if the sub-task estimates are ignored, how would I even know whether the task as a whole can fit in a sprint unless I add the sub-tasks manually and key in the information manually at the task level? (I mean, it's a computer. Arithmetic is literally it's "thing".)

But if those ARE true, I suppose that leads back to your recommendation that I not estimate anything smaller than a task. My projects are small, they aren't THAT small. How does Jira recommend dealing with estimates more complex than 2 levels? 

If I'm stretching it beyond what it was designed for, I can accept that and look for another solution, but what I'm hearing is just so bizarre that I'm having trouble believing that we're on the same page, and if it CAN work, I don't want to just pass on it because of a miscommunication.

[Nic Brough -Adaptavist-]

Again, the sub-tasks are not sprint items.

In scrum, you commit to delivering a set of items, not bits of them.  You estimate the items, not parts of them.  And you deliver the items, not bits of them.

All sprint items should have estimates that fit within the sprint.  If you can not estimate an item low enough to fit, then you split it into many items.

Sub-tasks are purely fragments of items.

Now, there's nothing wrong with estimating sub-tasks, but because their estimates are not relevant to the sprint, Jira simply ignores them.  If you want to use estimates on sub-tasks, you will need to come up with an automation that works out their effect on the story's sprint estimates.

[Kent Pilkington]

Maybe we're getting caught up in terminology, so let's see if we can work it the other way around.

Let's accept for the moment that only items can be delivered together. Is there another way to organize and group items that is more than an item, but less than an epic? This is where I would have expected to see a story, but even stories may need to be organized, as well as tasks within a story or task. 

Is that a possibility? Can the thing I'm looking for be accomplished by other terms?

[Kent Pilkington]

Or how would I do the automation you mentioned? The impact on sprint estimates is straightforward: I have a thing to accomplish in a given sprint. The thing has an time/effort estimate. That is its impact on the sprint estimate. How do I automate that? (Regardless of how it is grouped or categorized or broken out.)

[Nic Brough -Adaptavist-]

I'm sorry, it's not about terminology.  It is that putting estimates on non-sprint items is not going to work.

The way Scrum works means that you estimate on sprint items, not fragments of them.  If an item can not fit into a sprint, you split it up, lengthen your sprint, or convert it into an Epic/Feature that you can then break into several stories.

To estimate on sub-tasks in Jira, bearing in mind that they will still not be sprint items, you need to build an automation that can accumulate their estimate into a different field on their parent.

The most simple example would be to simply add them up:

• ABC-123 - story, 4h estimate
  • ABC-124- sub-task, 2h estimate
  • ABC-124- sub-task, 3h estimate

So you would write something that looks for every change of estimate on all of the issues and would write "9h" into a field called "sprint estimate" on ABC-123.  On server, I would do that with a scripted field, so that humans can't mess with the sprint estimate.

Adding them up is a bit clunky though, most people I've worked with who estimate on sub-tasks have been a bit more sophisticated - they still do the adding up, but also reduce the parent estimate each time a new sub-task is added.  This gives them the flexibility to create a story, estimate it overall, and then truly break it down into sub-tasks  which then contribute to it.

[Kent Pilkington]

"This gives them the flexibility to create a story, estimate it overall, and then truly break it down into sub-tasks  which then contribute to it."

Exactly (almost)! Except that in order to FIND the story estimate, you have to break it down and estimate the tasks and sub-tasks, right? To estimate an epic, you have to break it down into stories, stories into tasks, tasks into sub-tasks, sub-tasks into sub-sub-tasks, until you arrive at units of accomplishment that can reasonably and accurately estimated. I mean, that's the estimation process regardless of whether I want to add them to a sprint individually or in a group. If the software doesn't help me get a good estimate of the task, how will I even know what will work into a sprint?

But what I'm hearing (and just want to confirm) is that Jira is specifically designed NOT to do that calculation in order to enforce a strict 2-level hierarchy in which estimates are ONLY supported for tasks, and while you are technically allowed to estimate more granularly than that one single level, they will be purposefully ignored unless you REALLY want it to and are willing to do a lot of extra work and checking or automation to make it happen. And the reason that they will be purposefully ignored and not rolled up (as they are from tasks to epics) is because of the belief that if the task is part of a larger task, then it can't be added to a sprint? (Except that it can, because the task can be added, which would add any sub-tasks, but their estimates just won't be counted.)

Is that an accurate representation?

[Nic Brough -Adaptavist-]

I'm going to repeat your "exactly (almost)", but take a step back and try to talk in more general terms than I have before. 

And probably bore you to death with a bit of history.  I'll try to keep it short, but I'm afraid I am well known as a rambler, so it's probably still going to be a large pile of words to plough through.

I started with Jira 2, which was very new at the time, and my first tasks over "learn to be admin" were "merge into it from that Jira 1 over there" and "start worrying about the release of Jira 3".  I can't really talk about Jira 1, I only ever used it to extract some issues to import, so please don't apply anything I say below to Jira 1.

Jira was built as an issue tracker.  It was aimed more at small, non or partially Agile teams, often ones working in bigger organisations, than it is at large teams or even Agile groups.

When I inherited my first one, some of the teams using it were doing Scrum and Kanban and others (and, to show my age, this was before the Agile manifesto was written).

At that time, there were no Scrum, Kanban, or other methodology support.  To be frank, it did the basics - Waterfall with some time-tracking.  It did do issues and sub-tasks, that was what was needed at the time.

Then Atlassian bought an app that supported Scrum and Kanban from a partner.  Rather than destroy everything people were doing in none-agile environments, they tried to merge it all.  It's sort of worked, we have a lot of flexibility, but at the cost of having admins have to understand everything, in more detail than most of us want.

This loops us back to the big question, but leads to a short and easy clarification.

How are your teams wanting to work?

• Scrum
• Kanban
• Waterfall
• Something between two of them
• And how do you take that up above single team level

That's going to determine how you do any form of roll-up.  The estimate stuff was built for a simple Waterfall case, story points for low-level Scrum and Kanban.

[Kent Pilkington]

No, I'm actually fine with having context. In so many other ways, Jira was just checking all the boxes that I need in order to just get on with the business of estimating and then managing my projects. This is a pretty big limitation and I'm struggling to understand it. So, what I'm hearing is that there's some technical/data organization holdover from previous versions and added on software that's causing this?

The way we want to work once in the development process is probably more Kanban - it seems to be what the rest of the team (designers) understand. I'm gradually introducing agile concepts, but that will be a while. I don't think I know enough about Scrum specifically to know exactly what does/doesn't qualify. Some things will happen waterfall-ish-ly, but not by design.

We currently use Trello for the Kanban reasons mentioned earlier, but I'd really had high hopes that Jira could replace it (which I suppose it could) but also integrate it with an estimation process and support a team that will hopefully grow. But as I said, even our marketing-focused websites aren't quite THAT simplistic and the tasks are just not one-dimensional. 

I suppose as a coping mechanism, rather than using stories or any kind of agile process, I could just make epics for every page (or complex page section), header, footer, back-end data type, etc., just so I can estimate the underlying tasks and have the numbers roll up in some sort of useful way. Maybe. With only one level of categorization, though, I'll probably need to use some kind of hyphenated naming scheme to indicate that things are part of a group, and only *actually* group them under epics where I absolutely have to in order to summarize the numbers.

It's a complete and utter bastardization hack of the system for something that to me sounds like the data is (potentially) already just lying there ready to be used, and just isn't for a totally unrelated reason (that it's not allowed to be in a sprint on it's own because it's one level below an epic, regardless of how atomic the tasks and sub-tasks actually are).

And definitely a sharp move away from Agile rather than towards. Fortunately, marketing websites are not as "application-ey" so user stories and such are not quite as core to it, but still. 

It's probably still a step up from an Airtable or a Google Sheet, just because I can move the estimated pieces onto a Kanban style board?

I keep hearing echoes of one of my old PM's talking about "snatching defeat out from the jaws of victory". I think it definitely applies here, especially if Jira takes the "it's not a bug, it's a feature" stance.

[Nic Brough -Adaptavist-]

Jira Software is built as a Scrum and Kanban tool.

In Scrum, you only estimate sprint items as that's where you are committing to a delivery.  Sub-tasks are not sprint items, they are fragments of their owning sprint item.

In Kanban, the cards are the estimate themselves, and Jira treats sub-tasks as simple cards, there's no real relationship between a sub-task and a parent issue.

So, in both cases, you do not use estimates on sub-tasks.

It's not a bastardization, hack or even a feature - it's supporting the processes as they are supposed to be done.

Estimating sub-tasks is indeed a sharp move away from Agile, because you are not doing Scrum or Kanban, and those are the two main ways people implement Agile.

[Kent Pilkington]

No, I meant making everything an epic just so I can do estimates would be bastardization.

So, If I have an epic that's really broad (like front-end user dashboards), and each dashboard has components that need to be estimated and built individually. I can't estimate or schedule a component for development because it's the third level down, which makes it a sub-task, which means it can't be on its own? (front-end user dashboards -> Dashboard A -> Component 1)

Component 1 may be ABSOLUTELY appropriate for scheduling to a sprint on it's own, but you're telling me that the methodology says I can't do that because I can only commit to doing a dashboard (level 2), not a component (level 3), and the reason is because a component is the 3rd level down in organization? That can't be right. What if I have different developers working on different components with different availability and skill levels, so the estimates may vary? Nope. Why not? 3rd level. All or nothing.

I need to hit up some of my scrum master friends because that cannot be a real thing. Jira limitation, surprising, but OK. But that can't be a thing with the methodology as a whole. 

[Nic Brough -Adaptavist-]

Again, it is not a limitation, it supports doing Scrum.

Which has nothing to say about sub-tasks; it just talks about sprint items. 

Sub-tasks are not sprint items, they are parts of sprint items.  It sounds like you are estimating it all at the wrong level.

If it turns out a component is a sprint item, then it should not be a sub-task; convert it to a story at your dashboard level so that you can treat it as a sprint item.

Jira has sub-tasks, but they are only there in a Scrum setup for the team to be able to break up a story into pieces (mostly so people can work on different bits of a story during the sprint, to show there are different skills needed, or even just to show A developed it, B reviewed it and C tested it).

Kanban ignores sub-tasks.  Every issue is a Kanban item and they're all the same size.  It works on throughput, not estimates.  If you have Kanban teams working in a scaled Agile structure, it's very common to compare with the Scrum teams and agree on a simple "every Kanban card is 3 story points" equivalence, so that you can roll it up.

[Kent Pilkington]

I hear you on Kanban. It works for really small/flat projects.

"convert it to a story at your dashboard level"

It doesn't seem to matter whether it's a story or a task, it still won't roll up any estimates from pieces - and please don't tell me that it's because they can't be added to a sprint. They still take time and effort even if they have to be added as a group. They still may have to be estimated individually in order to arrive at the group estimate.

"Jira has sub-tasks, but they are only there in a Scrum setup for the team to be able to break up a story into pieces (mostly so people can work on different bits of a story during the sprint, to show there are different skills needed, or even just to show A developed it, B reviewed it and C tested it)."

OK. But I need to ESTIMATE them so I can get a handle on what the story's estimate might be. Lol. That's all I'm trying to do at this point. It doesn't matter what size chunk I'm going to add to a sprint, if I can't effectively estimate them without refactoring everything to being a task/story, it doesn't work.

At this point, it sounds like it's just not the right tool for the job. Whether it's tasks or stories, there's only one layer of things that can be estimated and totaled. I might still be able to use the Kanban aspects of it, but I think for now I'll just have to go back to an AirTable or something like that. There's just not a sufficient level of organization. I'll waste too much time working around the limitations.

Thanks for your time and effort, though. I'll be talking some of this over with a colleague this weekend who uses Jira regularly, so maybe he'll have a different take.

[Nic Brough -Adaptavist-]

Yes, that's exactly the point.

Sub-tasks are not sprint items.   They do not go into sprints.  They are part of their parent story, not a separate entity.

Have another look at the scrum process - there is no "partially done", a sprint item is either done or it is not.  Parts of it being done is not relevant and hence their estimates are useless.

By all means, estimate on sub-tasks, but that can't be used as a sprint estimate, and you will need to come up with a way to represent it on the parent sprint items.

If you move to another tool, that's fine, there are lots of others that can support your non-Agile processes (and that includes Jira Work Management, which I think might work rather well for you because you get some simple boards with JWM projects that do not try to be Agile - it's only Jira Software boards that do the two most-used Agile board types)

[Kent Pilkington]

Well, I think Jira would actually work REALLY well if it just had the ability to group tasks/stories in more levels than just epics. Everything else fits pretty well. There's just no way to organize tasks or stories except for the one level of epic, and that's a deal-breaker. As I said, my projects just aren't that simple. We'll still move in an agile direction. We just need to be organized.

[Nic Brough -Adaptavist-]

You can always go premium to get Advanced Roadmaps, or get one of the apps that extends upwards.  Easy Agile, Big Picture, etc.

[Make A Tea]

To acquire Advanced Roadmaps, you can always upgrade to a premium plan or download one of the upward-extending applications. Big Picture, Easy Agile, etc.

Like

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Do not put sprint estimates on sub-tasks.  They are not sprint items, they are fragments of their parent story, so putting sprint estimates on them makes no sense, and Jira won't look at them.

I can't replicate your backlog behaviour - if I create a task with an estimate and go into the backlog, the estimate is shown immediately, I don't have to click on the issue again to get it to appear.

Could you tell us exactly what you are doing to get this behaviour?  (Is it, for example,  create issue without estimate -> look at backlog -> edit issue, adding an estimate -> refresh backlog page -> go into issue again -> refresh backlog page)