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 good are tasks in Jira Agile?

Deiter

I have a few problems understanding the role of Tasks in Jira Agile:

Let’s say you begin a project by coming up with stories to describe the usages and you make estimates in Story Points like this:

Story: Open Bank Account | 4 Story Points

A couple of sprints into the project you decide it’s time to implement the story. Before jumping into Jira, you take some time to break the Story down into tasks and use Story Points to estimate them:

Task: Open Bank Account | Get Customer Details | 1 Story Points

Task: Capture an Image | Validate SSN | 2 Story Points

Task: Open Bank Account | Get Credit Score from Credit Bureau | 2 Story Points

Task: Capture an Image | Validate Visa Credit Card | 2 Story Points

Right off you notice that the total Story Points for the tasks (7) is greater than the original estimate (3). That’s OK; it’s common in an agile process, so you go ahead and create Jira Tasks for the items.

The first thing you notice is that there’s no Estimate field for Tasks, so you configure your board’s Estimation | Time Tracking to Remaining Estimate and Time Spent. Now you can enter time remaining. You realize that time remaining is in real hours, not Story Units, but it’s also common to use real hours for tracking and Story Points for estimates, so you convert to real hours. Let's assume 8 hours for the first Task and 16 hours each for the other three, for a total of 56 hours.

What to do now? I could push both the tasks and the story into the Sprint, but I’m concerned about double counting because I have both the story and the tasks required to implement it in the backlog and both have a duration associated with them (more on this later). In order to avoid double counting, I convert the Tasks to sub-tasks of the Story. That sounds reasonable, given that tasks are defined as a unit of work contained within a story. However, the backlog must be sorted in RANK order to plan a sprint and sub-tasks cannot be seen when the backlog is sorted that way, so those 4 sub-tasks will not be visible during sprint planning – a real inconvenience.

Frankly I can’t see a use for Tasks. Jira Agile defines Tasks as a unit of work contained within a Story, so frankly I’m a little surprised that Jira Agile allows standalone tasks at all.

Once I’ve established a velocity, I can use it to predict the end date by dividing the total estimates of all the issues in the backlog by the velocity. I guess the crucial question is this: Do I consider the estimates on Tasks, or only Stories? What does Jira do?

I have a feeling that it’s the Stories that matter and Tasks can be thought of as “drag”. In the example above I would add both the Story (Open Bank Account) and the 4 Tasks to the sprint. Let’s also assume Open Bank Account is the only story in the sprint, if I was miraculously able to close the 4 tasks during the (2 week) sprint, I would also close the Story and the velocity would be 2 (4 Story Points / 2 weeks). I could then divide the total of all the stories in the backlog by 2 to determine the number of weeks left. Similarly, If I wasn’t able to close all the tasks, I would move the Open Bank Account story and all remaining tasks to the next (two week) sprint. If all the tasks were completed in that sprint, I’d close the Story and the velocity would be 1 (4 Story Points / 4 weeks).

Is this how it works?

Thanks,

Dieter

Capture.PNG

Accepted answers

All comments

Nic Brough -Adaptavist-

Sub-tasks are a handy way to split stories up when they need to be worked on by more than one person, or just when developers feel that it's useful to break it up in to components.

I'd skip the estimates on them - the time tracking is useful for logging work, but, as you suspected, not estimates.

(By the way, "Based on the metric we adopted for Story Points, I estimate 8 hours per story point" - that's wrong I'm afraid. A Story point is not a measure of time)

Deiter

Thanks. You are right about the story points. I realized that after posting. We've based our Story Points on "Ideal Days" from previous work. 1 story point for one ideal day, or 8 hours. It would be much longer in real time, I merely wanted to point out that I converted it to real time. I've edited the query above accordingly.

Unfortunately I don't feel any further ahead understanding the distinction between Stories and Tasks and how they affect project completion date projections, although I feel that I may have worked it out as I wrote the post. I'm looking for confirmation.

It seems to me that:

I can use velocity along with the total estimate of all Stories remaining in the backlog to project completion date. The number of Tasks in the backlog and their estimates do not affect completion date projections directly. Instead they can be thought of as drag. They must be completed, so they reduce velocity on the Story cases and thus affect completion date projections indirectly.
When setting up a sprint with Stories and Tasks, I don't need to worry about "double counting". I can add a Story to a Sprint along with all the Tasks required to implement it (I can add unrelated Tasks too). Furthermore the Tasks don't have to be formally linked to a Story (e.g. I don't have to make them sub-tasks). I simply close the Tasks as they are completed and once the last task associated with a Story is completed and closed, I close the story as well. If I can't complete all of the tasks one in the sprint, the Story doesn't get closed and velocity drops.

Nic Brough -Adaptavist-

Ok, the sub-tasks shouldn't affect your velocity. They're there to break up stories into smaller pieces for a number of reasons, but the story points are on the story.

If a new task is a new piece of work that you have to do, then there are a couple of options. If it is definitely part of an existing story, then add a sub-task for the new work, but increase the story points on the parent story. If you want to tackle it separately, then add it as a parent issue type as though it's a new story. (It's very common for JIRA users doing Scrum to set up their projects so that all the parent issue types can be story-pointed - bugs, tasks, issues, new features, etc)

Deiter

Thanks Nic, I truly appreciate the support. Sorry to belabor the point, but I’m still unsure about the relationships between Stories and Tasks (not sub-tasks), which makes it difficult for me to be comfortable enough to trust what Jira is telling me about the state of my project, especially the version release date.

First off, I can accept the need to adjust a Story estimate as you indicated for new work, that’s the same as scope creep. However, the scenario I presented doesn’t involve new work, rather it’s a situation of an underestimated story, one in which the sum of the Tasks required to complete the Story is greater than the Story estimate. The documentation here suggests not changing the original estimate in such cases and does a good job of explaining why.

The other difference between your recommendations and the scenario I presented is you keep referring to sub-tasks, whereas I’m asking about straight up Tasks. I’m not so concerned about sub-tasks because the user is explicitly indicating to Jira that the sub-tasks are associated with the story. While I’m still uncertain how Jira uses Story estimates and the time remaining on Tasks to project the version release date, I’m reasonably confident that given the explicit relationship between a Story and it’s sub-tasks, it won’t “double count” by including both the Story estimate and the time remaining on the sub-tasks.

The problem with sub-tasks is they cannot be seen while Sprint planning because the backlog must be sorted in Rank order. This limitation makes sub-tasks difficult to use IMO, so I’m interested in using Tasks. The user doesn’t explicitly define a relationship between a Story and a Task in Jira, so I remain concerned how a Story and the Tasks required to implement it are handled by Jira. Maybe I should pose the question differently:

How is the version release date determined?

I believe that it’s a matter of measuring sprint velocity and then apply that velocity against the estimates for all remaining Stories, but not the Tasks. In other words, Story Estimates are used to predict the version release date, but the Tasks are used exclusively for time tracking. This is implied in the Estimation is different from tracking section of the documentation page here and makes sense given that Stories are normally measured in Story Points whereas Tasks are measured in real time units (hours, days etc.). If I have it right, adding a Story and the Tasks required to implement it to a Sprint is OK. If all the Tasks get completed, I can close the Story and velocity does not go down. If all the tasks cannot be completed, the Story gets snow ploughed to the next sprint (with the same estimate), and velocity goes down. Do I have it?!! If not, how should I handle situations when I have Stories and Tasks (not sub-tasks)?

Last question:

Where can I find the version release date Jira predicts? A similar question was asked before here, but not answered. I’ve added everything I want to release to a version so I’m expecting to see something on a version report following the first sprint once velocity is defined (although a default velocity might be nice). I’m wondering if there’s another way.

Finally, in my original post I suggested converting the Tasks to Stories and deleting the original story. That is likely not a good idea after all because it amounts to changing the original estimate, which is not recommended. I’ve modified the original post accordingly to avoid misinformation.

Thanks again!

Tim Walker_5omgux

Tasks belong on a piece of paper - the next test to write - and scratched off and added to as discovered. They do not belong in the ALM tool and they certainly should not have estimates on them.

They're so bad. So very bad. They lead to "Following a plan over responding to change", Decomposition across horizontal technical slices, communicating through the tool, inviting Parkinson's law on every task, makes standup just suck,

I can not think of anything nice to say about them. They're just waterfalling your stories.

Nic Brough -Adaptavist-

No. If you stick them on a piece of paper, and without estimates, how do you measure progress? Or velocity? Or what people are doing.

It's the complete opposite of "waterfalling your stories", it's "making them transparent, accountable, flexible and measured".

I'm sure you would be delighted to see a team who turns to your product owner and says "we didn't do anything this sprint because TASKS".

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software