How is the story point system implemented in jira?

Tobi Schulte July 9, 2015

I can set story points for Stories and for Tasks. Let us say I have the

userstory "As a scrum master, I can see the progress of a sprint via the burndown chart"

Now I have multiple tasks and subtasks to this userstory. Where do I set the storypoints now?

For a good project management I have to set them always at the smallest unit. Let us say I have Task1 with Subtask1 and Subtask2. Now I have to set the storypoints for Subtask1 (4) and Subtask2 (20). But this has to add up in Task1 to 24. If I do not have any subtasks for Task2 (26 Points) then I have to set the points for the task directely and everything would add up to 50 Points for the Story. In this example it would be not allowed to set any points neither in the story itself nor in the Task1.

 

Is this possible to achieve in JIRA or what is the common way to implement something like that?

 

2 answers

0 votes
Tony Laycock July 15, 2015

Basically, JIRA Agile is setup to support two parallel estimation approaches:  

  • Story Point, on Story Issues and Epic Issues, for medium term planning
  • Man Hours, on Sub-Tasks, for intra-sprint planning

See full explanation here:

http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/

Hence, the 'smallest unit' scenario you describe isn't relevant for stories and sub-tasks because they use different estimation units.

However, the situation you describe is completely relevant for Epics & Stories.  They both use SP estimates and it would be natural to expect that plans and projections would be based on the 'smallest unit' approach you describe.  i.e. use child story estimates where possible but drop back to the epic level estimate if the child stories haven't been created / estimated yet.  

Unfortunately, JIRA doesn't help with this.  Reports are based on story OR epic estimates but never the best mix of the two.  JIRA doesn't even recalculate the Epic SP estimate based on sum of child stories.

My company's workaround is to manually make sure that estimates are EITHER held at Epic or Story level, but never both.  i.e. so when an Epic has been fully decomposed and its child stories estimated, we will go back and blank out the Epic level estimate.  That way we can sum both stories and epics without fear of double accounting.

 

 

Suggest an answer

Log in or Sign up to answer