0

My team and I have recently adopted Scrum, and we've chosen Jira as our primary tool for managing sprints and backlogs. As we navigate our sprint planning, we're grappling with an issue related to the estimation of story points and their relationship with sub-tasks.

Here's the challenge:

When creating a user story, we don't always have a full picture of the required sub-tasks. As the sprint progresses and the story is further refined or work begins, more sub-tasks become apparent. We've been assigning story points to each of these sub-tasks based on the anticipated effort. However, when trying to automate the summation of these points to reflect at the parent story level in Jira, we run into a problem. If, for example, a user story ends up having two sub-tasks, each estimated at 5 story points, Jira sums the story points of the parent story (which would be 10) with the sub-tasks, resulting in a total of 20 story points. This not only skews our sprint velocity but also misrepresents our initial estimation.

I realize there's a variety of opinions on whether or not sub-tasks should be assigned story points, but given our evolving understanding of user stories and their subsequent sub-tasks, how can we accurately aggregate the story points in Jira without this double counting? Also, if there's a more efficient strategy for managing story points in relation to emergent sub-tasks, I'd greatly appreciate your insights and recommendations.

Improve this question

1 Answer 1

Reset to default
1

Jira doesn't give much control over how story points are aggregated together out of the box.

There are some plugins that allow you to do complicated JQL. An example might be to use these plugins to sum the sub tasks' story points together and use the value to populate the parent story's story point field. Another alternative would be to use the API and do the calculations externally to Jira and then repopulate the field. Both of these approaches are complicated and are likely to be time-consuming.

As an alternative to your suggested approach you could simply ignore the effects of discovery (i.e. when new work is discovered during a sprint).

Story points and velocity are designed to be resilient against the effects of discovery. This is because while individual story point estimates may be wrong, they will be smoothed out by the rolling average velocity calculation.

You can also learn from your mistakes in sprints. Discuss at the retro the stories that grew in size during the sprint. Are there things you can do to reduce the chances of this happening? Would reducing the size of stories help? Perhaps there is a particular story type that tends to be under-estimated?

This is the classic Scrum approach: inspect and adapt, learn from your mistakes and use emperical measurement to smooth out your errors.

Improve this answer
2
  • 1
    Thank you for your detailed response; it provides a lot of clarity. We will certainly have to look into the idea of focusing on the inspect-and-adapt principle of Scrum during retrospectives. On another note, apart from the stories that grow in size, how do you suggest handling stories that are bigger than our 2-week sprints. Should we break them down further, even if it leads to somewhat artificial boundaries, or is there another approach that might be more effective?
    – mkr
    Commented Sep 8, 2023 at 9:32
  • 1
    Breaking down stories is a skill that your team will develop over time. Right now it likely feels difficult to break down some of your larger stories, but I promise you the team will get better at it if they stick to the approach of 'smaller is better'. I would recommend searching the Internet for approaches to breaking stories down. There are lots of really good techniques for this.
    – Barnaby Golden
    Commented Sep 8, 2023 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.