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; } } }

Subtask type effort in plan mode of Greenhopper

Bernd

Hi,

we are using 3 sub task types for our stories. Is there a way to show the effort (capacity planning) only for a certain type of subtask in plan mode? I already tried to quick filter (e.g. type = "SubTaskType1") the types but the stories (which would show the effort) won't be displayed :-(

Accepted answers

Bernd

1.) Yes we use story points. But after the detailed planning (all sub tasks created) we would like to know the hour based effort for the QA, DEV and ID members.

2.) If the capacity is enough, everything is fine :-) Otherwise we can for example split the story or do other things.

3.) This is the ideal scrum approach :-) But because of different knowledge not everybody is able to do everything ;-)

But back to the original question: The answer is "no it is not possible (not even via a complex quick filter?) to only show the story and a certain subtask type in plan mode", isn't it?

All comments

Timothy

Don't think there is. GreenHopper does not support thee concept of estimating on the sub-task level.

YC Lian

Like what @Timothy said, I don't think so either.

But, is there any reasons why you want to see it in "Plan" mode? Is there a reason why they are not a Story instead of a (Sub-)Task (that the latter will eventually be closed as part of a Story at the end of a Sprint)?

And, are you a Developer?

Bernd

Our team conissts of QA, ID and DEV members.

Subtask types are DEV, ID, QA

Here is an example

Story 1 "Create first new feature"
- 2 DEV subtasks each 4 hours

- 1 ID subtask 2 hours

- 3 QA subtasks each 2 hours

-> 16 hours

Story 2 "Create second new feature"
- 1 DEV subtask 1 hour

- 2 ID subtask each 3 hours

- 1 QA subtasks 1 hour

-> 8 hours

In plan mode I will see that a capacity of 24hours is needed to complete both stories in the sprint.

The QA members have a capacity of 6 hours, DEV 10 hours and ID 8 hours -> 24 hours but will be the sub team capacity enough?

"Filter" for DEV:

Story 1 "Create first new feature"
- 2 DEV subtasks each 4 hours

Story 2 "Create second new feature"
- 1 DEV subtask 1 hour

-> 9 hours

"Filter" for ID:

Story 1 "Create first new feature"
- 1 ID subtask 2 hours

Story 2 "Create second new feature"
- 2 ID subtask each 3 hours

-> 8 hours

"Filter" for QA:

Story 1 "Create first new feature"
- 3 QA subtasks each 2 hours

Story 2 "Create second new feature"
- 1 QA subtasks 1 hour

-> 7 hours

QA capacity is too less maybe we pick another story...

YC Lian

The QA members have a capacity of 6 hours, DEV 10 hours and ID 8 hours -> 24 hours but will be the sub team capacity enough?

My first question is, what do you mean by "enough"? Don't you plan your Stories based on complexity (usually meassured using Points, and are roughly estimated based on yesterday's weather)?

Second question is, if you realize that the team is available (in terms of "capacity"), what will you or they do?

Third question, why are you separating them into three teams? Why can't they all be just one single team and we measure the outcome (the product, which matters) of the team instead of the hours they have spent?

Bernd

1.) Yes we use story points. But after the detailed planning (all sub tasks created) we would like to know the hour based effort for the QA, DEV and ID members.

2.) If the capacity is enough, everything is fine :-) Otherwise we can for example split the story or do other things.

3.) This is the ideal scrum approach :-) But because of different knowledge not everybody is able to do everything ;-)

But back to the original question: The answer is "no it is not possible (not even via a complex quick filter?) to only show the story and a certain subtask type in plan mode", isn't it?

YC Lian

And that's the thing I'm questioning - why is "capacity" a matter? If the testers have nothing else to do, ask them to learn what the other guys or doing, or spend time onother chores such as functional and non-functional testing.

What really matters is whether Stories and Sprint goal aligned, not whether people are available and filled with tasks.

Chris McFadden

I agree that there is a need for what you ask for. We have developers, functional test engineers, and special performance test engineers. While they collaborate together to complete the stories, there is specialized expertise that is not possible to completely make the team members fungible.

To solve the capacity problem, we use an old fashioned Excel spreadsheet during Sprint Planning. We first determine capacity for each person for the sprint (deducting for time off, slack, etc) and roll up to the three categories of hours. Then as we go through each story in order we add up the sub-task hours for dev, test, performance and keep a running total. When we run out of hours we stop.

Bernd

I have created the issues GHS-9178 and GHS-9179 for this. Please vote :-)

Bernd

As long as atlassian does not provide the feature out of the box, the "Aggregation gadget" of the "Project Metrics" plugin does the job.

Welcome!

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

Quick Links

Find more posts tagged with

jira-software

jira-administration