nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rapid Board - Story Points and sub-tasks - Aggregate Estimates "up"

Ivar

Today I started using the Rapid Boards for the first time in our team. And I was quickly struck by something that seemed weird - our story point estimates on subtasks wasn't aggregated up to the parent story, hence I get the "error message" that I haven't estimates issue X, Y and Z when I select "Start sprint". This was obviously wrong, but I assumed it had something to do with a configuration missing than anything else.

A couple of hours later I'm quite baffled. It seems that estimates in story points on subtasks are ignored by GH. It only cares about story points on the parent issue. Hours on the other hand can be included if the user configures this for the specific board, but story points are ignored.

After further reading the blog (http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/) I understood that this was intentional, and that Atlassian doesn't seem to have any plan to include aggregation for story points in the future.

The team I work with is a product team. We have a big backlog, and we do not estimate the user stories when they are added to the backlog. The backlog is used as just that, a backlog, and we plan the sprints based on what is most important for the business at all times.

So how do we plan the sprints? Before every sprint planning, the product owner and I sit down with the backlog and prioritize the issues using business value. Some issues have been estimated before, but moved back to the backlog, while other issues are "clean" in regards to estimates. So we add a "decent" amount and await the sprint planning result.

During the sprint planning the team breaks down all user stories into sub-tasks and estimate them in story points. To make sure we are relatively sure of the estimates, we do not allow for a larger estimate than 8 story points. And btw - story points are only considered in regards to complexity not 1 sp = X hours.

After the sprint planning I sit down with the product owner again and consider the total estimate for the sprint vs. the velocity. If there are big gaps, we remove the issues that are the least important to the business. And we end up with a sprint the team can commit to.

This has worked quite fine for several years now. But it seems that Atlassian doesn't want to support this way anymore - I have to do something else.

It seems that it all comes down to estimate vs. tracking? E.g. that the user story should be estimated in regards to other user stories (e.g. user stories and complexity, 1 being bigger than the other), and that sub-tasks just as well can be estimated in hours (something we have been moving away from for 3.5 years now).

Am I completely misunderstanding something here?

Accepted answers

Ivar

I found this issue that I've voted for: https://jira.atlassian.com/browse/GHS-7719

All comments

RicardoA_8cz081

Hi Ivar

Planning the sprints will rely on your business rules, every client can plan the sprint differently, but they will always have to use issues for it.

Regarding story points and sub-tasks, as you already stated GreenHopper will not sum the sub-tasks in the task and also, you will not be able to finish a task in the sprint if the sub-tasks aren't all completed. We reccomend you creating one task instead of sub-task and create a epic label, that way you can keep track of all the tasks that belong to the same "task force". Please refer to this documentation regarding epics: https://confluence.atlassian.com/display/AGILE/Working+with+Epics

You can take-off tasks from the already started sprint, but agile methods don't reccommend it. Just right click at the issue and select remove from sprint.

Hope it helps.

Ricardo Carracedo.

Ivar

Ricardo, I'm sorry to say that your answer didn't really give me anything. Of course a user story (task) isn't complete before all sub-tasks are resolved.

And we are already using epics today to link things together - however, we are using regular "link issue" because we haven't started to use rapid boards yet.

My main concern is that rapid boards doesn't sum the amount of story points on the sub-tasks. But it does for estimate in hours. Something that doesn't add up for me. Why choose one estimate type but not the other?

If we are going to start using rapid boads, which I guess we have to if we want to continue to use Jira as the classical boards will die sometime in the future, we will either have to change our development process and introduce an "immediate estimate from the team lead" once an issue has been added to the backlog and then double up on the number of story points per sprint (the original guestimate from the team lead + the number of story points for the sub-tasks once estimated in the sprint planning), or we change estimate technique and start estimate sub-tasks in hours instead.

For the second part, the burn down for story points will look bad as you will (potentially) have 0 story points resolved for the first days, and then get big jumps when the user stories gets resolved - in this case I guess it is only the burndown of hours that will indicate if we will hit the target or not.

For the other part, if we double up the story points I guess we will get a burn down that behaves better, but I'm still not sure it will be better for us.

Thing is - this has been working just fine for years, now rapid boards changes everything (at least, it seems).

Bill Langton1

Hours on the other hand can be included if the user configures this for the specific board, but story points are ignored.

I'm not seeing hours rolling up in GH either.

https://answers.atlassian.com/questions/204223/project-board-and-time-estimates

Ivar

I found this issue that I've voted for: https://jira.atlassian.com/browse/GHS-7719

Nils Boe Erikse

Can this be really true that it is so complex just to add a feature being able to customize the rapidboard.

to show what is required for the given project or customer.

Jayson Ambrose1

I think there is a misunderstanding of how estimating and planning should work in an agile evironment. User stories are a feature. "As a user, I should be able to create sub-tasks for user stories."

This is the "card" that moves across the board. When doing high-level planning (say for an epic, the quarter, the year, etc...) you should as quickly as practical assign story points to the stories. These should be an estimate of relative size: 2 is twice the size as 1, 10 is twice as large as 5, etc...

This should be enough information to establish velocity over several sprints and allow you to schedule several or many sprints into the future.

During iteration planning (start of a sprint) the team adds all the relevant sub-tasks to that story and estimate each of them in hours.

This book did a very good job of helping my understanding of best practices for Scrum: http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

Ubisoft1

Hello,

I have made a workaround

I did a little something its not perfect at all should any of you do better just put it here.

- It add a button left of PLAN mode

- It work only for certain user since it can create a load on the isntance (get the issues data in rest)

It add the sum of subtask instead of story point/time estimate when you click on it. Also add a custom field (we have another kind of priority system). You can use it to add story point or time, its like you want easy to edit.

Add this code into the Announcement banner

<script type='text/javascript'>

AJS.$(document).ready(function () {

    var username = AJS.$('#header-details-user-fullname').attr('data-username');

    console.log(username);
    if (username == 'name1' || username == 'name2') {
        var path = window.location.pathname;
        console.log (path);

        if (path.substring(path.lastIndexOf('/') + 1).indexOf('RapidBoard') > -1) {

            AJS.$('#ghx-modes').before('<button class="aui-button" id="add-ubi">Show CF and Aggregate Time</center>');

                AJS.$('.add-ubi').on('click', function () {

                    $('add-ubi').trigger("click");

                });
                AJS.$("#add-ubi").click(function () {

                    //AJS.$("#add-ubi").toggleClass("active");

                    //AJS.$("#add-ubi").remove();

                    AJS.$('.ghx-issues > div').each(function () {

                     try {

                            console.log('Found issue list in sprints');

                            var row = this;

                            var issueKey = AJS.$(this).attr("data-issue-key");

                            //console.log('Found issuekey' + issueKey);

                        if (issueKey)

                        {

                            

                            AJS.$.getJSON(AJS.contextPath() + '/rest/api/latest/issue/' + issueKey, function (data) {

                                console.log('Got data for - ' + issueKey);

                                if (data.fields.customfield_10222 || data.fields.customfield_10222 != null)

                                {

                                    var value = data.fields.customfield_10222.value;

                                    if (value.lenght)

                                    {

                                    value = value.replace("'", "\'");

                                    var actions = AJS.$(row).find('.ghx-end');

                                    AJS.$(actions).before('<style type="text/css"> .ghx-issue-compact .ghx-end-ubi{position:absolute;right:-20px;top:5px;}</style><div class="ghx-end-ubi"><span title="Ubi Priority">' + value + '</span></div>');

                                    }

                                }

                                if (data.fields.aggregatetimeoriginalestimate)

                                {

                                    var value2 = data.fields.aggregatetimeoriginalestimate / 60 / 60 / 8;

                                    var actions2 = AJS.$(row).find('.ghx-end .aui-badge');

                                    AJS.$(actions2).html(value2.toFixed(2).replace(/[.,]00$/, "") + "d");

                                }

 

                            });

                        }

                     }

                        catch (ex)

                        {

                            console.log ("ERROR");

                        }

                    });

                    AJS.$('.js-issue-list > div').each(function () {

                        try {

                            console.log('Found issue list in backlog');

                            var row = this;

                            var issueKey = AJS.$(this).attr("data-issue-key");

                        if (issueKey)

                        {

                            console.log('Found issuekey' + issueKey);

                            AJS.$.getJSON(AJS.contextPath() + '/rest/api/latest/issue/' + issueKey, function (data) {

 

                                console.log('Got data for - ' + issueKey);

                                if (data.fields.customfield_10222 || data.fields.customfield_10222 != null)

                                {

                                    var value = data.fields.customfield_10222.value;

                                    console.log("we are inside of value" +issueKey)

                                    value = value.replace("'", "\'");

                                    var actions = AJS.$(row).find('.ghx-end');

                                    AJS.$(actions).before('<style type="text/css"> .ghx-issue-compact .ghx-end-ubi{position:absolute;right:-20px;top:5px;}</style><div class="ghx-end-ubi"> <span title="Ubi Priority">' + value + '</span></div>');

                                }

                                if (data.fields.aggregatetimeoriginalestimate != null || data.fields.aggregatetimeoriginalestimate != 'undefined' || data.fields.aggregatetimeoriginalestimate != "" || data.fields.aggregatetimeoriginalestimate.lenght != 0)

                                {

                                    var value2 = data.fields.aggregatetimeoriginalestimate / 60 / 60 / 8;

                                    var actions2 = AJS.$(row).find('.ghx-end .aui-badge');

                                    AJS.$(actions2).html(value2.toFixed(2).replace(/[.,]00$/, "") + "d");

                                }

                           });

                        }

                    }

                            catch (ex)

                    {

                        console.log ("ERROR");

                    }

                    });

        });

    }
}

});

</script>

Moriah Chandler

Working with support from Arsenale Dataplane, we are now able to view a report that includes epics, the stories in those epics, and the subtasks for those stories. Though we are using Dataplane (a paid addon), the scheme for setting up a scripted field that can be used to "segment by" epics is still useful without it.

How Dataplane solved the problem for me:

Install Script Runner addon (free).
Create a new Script Runner custom field ("Scripted Field") in JIRA, called "Master Epic" (or something similar). Here's Arsenale’s own Dataplane primer on how to set up and use Scripted Fields. Here's a more general Script Runner primer on how to use a Scripted Fields. You are going to use this field to report on the Epic that the issue is a part of, regardless of whether the issue is a parent or a sub-task issue. Scripted Fields use programming script written in a language called Groovy. It's virtually identical to Java.
After creating the field, go to the Admin>Addons tab.
Click on “Script Fields” under the Script Runner section on the left.
Click Edit.
Enter the following script:
Reindex JIRA.
If you are using Dataplane, reindex it also.
In Dataplane you can create a report that uses this scripted field to “segment by”.

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.Issue;
 
CustomFieldManager fieldManager = ComponentAccessor.getCustomFieldManager();
CustomField epicLinkField = fieldManager.getCustomFieldObjectByName("Epic Link");
CustomField epicNameField = fieldManager.getCustomFieldObjectByName("Epic Name");

if (issue.isSubTask())
{
    issue = issue.getParentObject();
}

Issue epicIssue = (issue.getIssueTypeObject().getName().equals("Epic")) ? issue : issue.getCustomFieldValue(epicLinkField);

return (epicIssue != null ? epicIssue.getCustomFieldValue(epicNameField) : null);

Steve Vaughn1

Wouldn't it be great if the tool did not dictate how we run our teams. It seems like a logical feature to have sub task aggregate up to a story. Forcing teams to use hours in order for the burn down to work is illogical. JIRA is supposed to be a tool, not an Agile Methodology cop.

Korayem

Doesn't work

Tracy Reitmann

I'm having a similar issue – the teams I'm now helping use main stories and subtasks. In addition to not having the subtask points "add up" and total in the main story, there's also the resource tracking problem. You know those nice resource tiles at the top of each sprint in backlog view and you can expland it and see where all your people are working? it won't read subtasks. So I've had to resort to manually putting everything in excel. I work in a very large team - about 24 devs including a handful of QAs (I know, we're trying to figure out how to break them out into smaller teams).

If I could get them to only use Epics as their "main story" and instead of subtasks link the stories together the world would be a better place. But they're resisting, big time, so I'm researching.

Oskar Kamiński

Unit of tasks by definition has nothing to do with unit of user stories.
It is a common practices to use story points for user stories and for tasks. But these are different story points just like one's team story points are different than other's team story points.

They are incomparable as story points given to user stories are given with less knowledge than task points. It is your choice not to estimate stories (omit this step) and go straight to task estimation.

Task estimation is done only during sprint planning meeting to judge whether something can fit into a sprint.

Guess which story points are used to calculate the velocity of the team.... It's the PB story points.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

agile

sub-task

story-points

aggregate