How to manage story points when there are a number of tasks? [closed]

Question

I am trying to get my head around how story points are assigned to sub tasks and how the story points are managed in Jira.

I have a user story which we have estimated at 25 points. A developer will take this user story and split it up in to a number of tasks.

Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points? And if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?

Also, if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?

Answer 1

Let's pretend Jira isn't the issue for a moment.

First, tasks should be estimated in hours, not points.

Second, stories should only be counted toward the burn down when they're complete. (https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/)

Third, consider what value you are getting from the tasks. In teams where we have done tasks, I've found the work of creating the tasks a great validator of whether or not the story has been defined well enough. Marking off the tasks has been of less use to my teams.

Fourth, when a story is not complete at the end of the sprint, it should go back into the backlog for the product manager to re-prioritize. It may be that it's no longer a priority (especially if it's taking much longer than expected). https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint From teh scrum guide - "All incomplete

Product Backlog Items are re-estimated and put back on the Product Backlog."

Personally, I don't like to re-estimate because then some effort is "lost". If you don't re-estimate, then your velocity balances out over time, even if each individual sprint velocity bounces up an down.

In some cases, when stories tend to be large, when they are estimated to take more than 4 or 5 days you can easily lose track of progress within a sprint. This is especially true if the sprint is 2 weeks long.

Teams I've worked with have moved away from tasks in favor of smaller stories. (Currently, we use a rule that if it's > 13 story points, it's probably too big and should be split up).

All this considered, Jira should fall in line fairly well.

Answer 2

I find sub-tasks to be the hardest feature to use in conjunction with agile in JIRA. It always ends up being one of two scenarios, reminding why I try to never use sub-tasks to begin with:

1. Each sub-task is actually a story, and the initial story was way too broad. Every time I'm in this situation, the original story goes over 1 sprint, if not many sprints (causing the developer to rush, shirk, be stressed, etc)
2. Or, the sub-tasks themselves are too detailed and aren't worth putting in JIRA as their own issues; instead you should just add a comment to describe progress or ruminations to the original issue/story and avoid the JIRA overhead.

EDIT: In response to @DaveHillier

I don't like creating subtasks because it's more JIRA pushups. I think the allure of subtasks is that it makes your use of JIRA appear more structured, but I think an important part of using JIRA well is to keep issue count as low as you can, and yet still be effective for the team. I can't possibly justify this why I think issue count should be low in this thread, other than to say, ' with JIRA, less is more'.

Let me show you what I do that satisfies the following requirements:

• transparent progression on the issue (other users can be notified if they want)
• lets me organize my own thoughts
• remains inline with the issue, letting someone look at my one story and understand quickly where I'm at

I make a list in the description of my main story, using JIRA markup like so:

Build the thing. Lots of words blah blah.

h3. Progress
* code it
* test it
* deploy it

Then using JIRA markup, I can add little green checkmarks as I get done using (/) next to each bullet point, letting any 'listeners' of the bug stay abreast of my progress.

Build the thing. Lots of words blah blah.

h3. Progress
* (/) code it
* (/) test it
* deploy it

Answer 3

Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points?

No, tasks of a story are not assigned any points because one completed task will not provide much value to the client / enduser. All the tasks combined will deliver a working piece of code much would be of some value for the enduser. In essence a story is not complete till all of its tasks are done. Remember: Working software is the primary measure of progress.

if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?

Since task dont have any points (as mentioned above), this becomes obsolete.

if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?

If a story remain incomplete at the end of the sprint then you have two options, either move the whole story back to the product backlog or if any part of the incomplete story can be salvaged and treated as a working piece of software then split the story into two. Working part will be considered complete in the current sprint and non-working part will become part of the product backlog. This part will be treated as a new story and it should be estimated as a separate story. You cannot split story points between the working part and non-working part.

Answer 4

Sub tasks don't work well in with Jira Agile.

In my current team we don't use them.

I disagree with sethcall, that there are no reasons that I should be using sub tasks.

I'd like to track that I can't easily at the moment:

• tasks for completing each point of a definition of done
• tasks to make acceptance tests pass

There are plugins that support acceptance testing, (e.g. Behave for JIRA) however I have no experience of them.

Some have suggested to use custom fields for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list. Here is an article that suggests using checklists for acceptance tests. Might be worth a try.