Subtask type effort in plan mode of Greenhopper

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 :-(

5 answers

1 accepted

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?

0 votes
Timothy Chin Community Champion May 27, 2013

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

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?

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...

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?

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.

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.

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

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

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

239 views 0 11
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot