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.
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?
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)
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:
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)
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)?
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.
Ok, I'm really not sure why this seems to be so complicated.
Because of your questions about how "tasks" should interact with your stories, I think I've been focussing on sub-tasks, where all of the stuff about breaking up stories and estimating does matter.
So, I've misunderstood what you're questioning. For that, I do apologise, because it's completely failed to answer what you are asking about. (It is ok for sub-tasks, but it's not said a thing about the rest)
The really simple answer is that you can consider all issue types that are on the story level to be effectively stories. (Apart from Epics - they're Epics). Tasks, bugs, feature requests, etc. They're all "stories" as far as the Agile process is concerned, and JIRA Software reflects that. The easiest thing to do in your case is probably to forget that there's any difference between "stories" and "tasks".
Thanks a lot Nic. That helps and was how I understood it originally. It’s a pity that sub-tasks aren’t visible during Sprint planning because it sounds like that’s what I really need to use. I titled the post “What good are tasks in Jira Agile?” because if I wanted to break a Story down into Tasks (not sub-tasks) I’d have to adjust the estimate on the Story to account for the fact that some of the work had been moved to a Task. It seemed to me that if you have to do that, you’d be better off simply replacing the Story with a number of other Stories and thus why have Tasks. However, it sounds like sub-Tasks are the best solution here, despite the pain of not being able to see them during Sprint planning.
So, in terms of the question I asked: How is the version release date determined? It sounds like the version release date is determined by converting the estimates on all remaining Stories to real time using velocity and then adding them all up along with the time remaining on all Tasks. Assuming that’s right:
I appreciate you sticking with me on this. Understanding the relationship between Stories, Tasks and sub-Tasks and how they affect version release date enables me to make the right choices as I manage projects in Jira.
>It’s a pity that sub-tasks aren’t visible during Sprint planning
Sprint planning is about getting your backlog in a ranked order and building a sprint goal for the next sprint according to your capacity. Sub-tasks are not needed in sprint planning because they're useless there - it's nonsense to rank them outside their parent issues, and sprints contain the parent level issues
>if I wanted to break a Story down into Tasks (not sub-tasks) I’d have to adjust the estimate on the Story to account for the fact that some of the work had been moved to a Task. It seemed to me that if you have to do that, you’d be better off simply replacing the Story with a number of other Stories and thus why have Tasks.
Absolutely right - this is breaking up stories and then just using tasks instead of stories. They're just another type of issue at the same level as stories. When you split stories up like that, I'd say there's a weakness in JIRA in that I'd love an explicit "split" function which would create a new story (or other issue type in the project), ask me for the split of story points for old and new issue and duplicate loads of the fields, link them with a "was split from" link, and ask me to update fields in old and new to explain the split.
So, looking at the release date, not quite. Velocity based on story points or time estimates are different things - they're tools to help you work it out, but can't really tell you directly what you are going to release. You have options that fall on a scale.
At one end there's "finish a sprint, or get to a milestone and whatever we have at this point that works is the version". That can be easy because you essentially don't plan releases at all. But it does mean you can't really tell anyone when stuff is guaranteed to happen.
At the other end, you can plan a release to include a list of things. "We will fix these five bugs, and add that feature". You rank those items as high up the backlog as high as possible, and then the release date becomes "when we've done enough sprints to cover all that work"
Going back to the original, you'll note I've not mention sub-tasks at all in the release planning. Because you plan at a story/task/feature/etc level.
Thanks Nic. Very informative. I have all the issues I need to release assigned to a Version that I created, so I've identified what I want to release. The issues include Story issues and Task issues, so a combination of Estimates in Story Point and Work Remaining in real hours:
The Version Report on the All Reports page (below) indicates:Track the projected release date for a version. Doesn’t that suggest that Jira does generate a version release date? Maybe I have to wait for a Sprint to complete so a velocity can be established? Also, the burn down chart shown on the link you provided shows dates on the X axis, so it seems that calendar dates do get generated. It would be informative to know how Estimates in Story Point and Work Remaining in real hours are used to generate those dates.
OK a velocity calculation is used; that's what I was expecting. Tasks are involved here as well, so presumably the Version Report "Track[s] the projected release date for a version" by converting Story Point estimates to real time and adds in the Time Remaining on Tasks. I asked this earlier but I didn't quite understand your response: "Velocity based on story points or time estimates are different thing..."
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot