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?

Fortis

Generally speaking, subtasks don't have points. If a story is 25 points (which, if you're using the Fibonacci-based point system in agile, doesn't exist), it's probably too large (although its all relative to your own company). Subtasks are generally small pieces that say how you implement a story, while the story describes the actual functionality. Smaller stories allow you to implement small, but releasable, pieces of functionality. YMMV. – Mcclanahan

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.

Magi

On the projects I have worked on, the PO gave high level user stories and developers just got on with them. I think this was our main problem. Also because our last project was a re-write, we did not need the PO as much as the lead developer has most of the business knowledge and guided development. Thank you so much for the information provided. As I am now taking over the scrum side of the project, JIRA seemed overwhelming with charts showing burn downs per day for story points. I'll try not to get too obsessed with Jira and work on the wetware processes. – Fortis

Perhaps relabeling high level stories from a PO as "epics" or "features" that still must have stories below them created and estimated would be helpful to frame in jira terminology. An amazingly helpful book on user stories is "User Stories Applied" by Mike Cohn. Very helpful when considering when/how to split stories. – Magi

You mentioned story points should be burnt at the end. Why is it in JIRA there are charts which give daily burn downs over a duration of a sprint? – Fortis

Also, if your story is more than 5 days, what do you do? The story is a deliverable so do you just split it up and only deliver when both parts are done? – Fortis

1st question - I said story point should be burned down after the story is complete, not at the end of the sprint. Perhaps I'm misunderstanding your question? 2nd Question - If the story is estimated > 5 days, I would say to try to split it up and deliver as soon as makes sense. If the functionality only makes sense when both/all parts are complete, I would say to deliver to the customer when it's all done. But this is the PO's call. I would deliver internally before then though. To the PO for example. – Magi

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

Tenpins

I like the idea of using these checkmarks they're simple and light. I don't care about tracking the progress of these too much as stories not done until its completely finished. – Edd

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.

Badgett

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.

Edd

Thanks Dave. This is my first project using JIRA and in the past we have taken a user story, estimated it and then the developer has created a number of sub-tasks. Should we just have one Story and comments which represent sub-tasks? It just felt better for organisational purposes to have sub-tasks (remembering what to do, decomposing a user story etc). – Fortis

I always thought that sub-tasks where a developers way of organizing what work he had to do in the sprint whilst the user story defined by the developer and PO. I do not expect the PO to know about tasks. – Fortis

yeh, that would make sense to me too, but you can still link task to stories they don't have to be sub-tasks. – Edd