How to manage story points when there are a number of tasks?
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
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.