Combine bug time to story time

[Jack]

Hello,

I was just wondering if anyone had a easy way with TeamPulse to combine the time of a bug to its parent story?

If we have a story that has 20 hours of development time on the story, and 15 hours of time devoted spent across 5 bugs on the parent story...We would like to see that next to each other.

Story 12345
Development 20 hours
Total bug time: 15 hours
 bug 1: 3 hours
 bud 2: 5 hours
 bug 3: 0.5 hours
 bug 4: 3.5 hours
 bug 5: 3 hours

[Diana]

Hi,

if you are logging you time in the tasks of the story then you can use Analyze -> Time Entries to see totals of the logged time. 

In the next TeamPulse release we are planning to add on Story level rollups for tasks count and estimate. If you think that rollups for bugs would be valuable, we can consider adding such too.

Could you give us more details how you will track spent time and which functionality is most important for you?

Regards,
Diana
Telerik

[Jack]

Diana,

We create a Story "develop this web form" with the following 3 tasks.

• Specificaitons - What is this form supposed to do
• Development - Develop the specifications of the webform
• Testing - Test that the develop matches the specifications

We use the Estimate to gauge the length of time we expect to spend on this form.  Our point system is in hours.  So we say we expect this form to take 6 hours to develop.  This is our starting point
That is then broken down as Specifications are 1/2 the story estimate, Development is the full time and Testing is 1.5 times the estimate
The time we track under the tasks would be:  This means the completed story would be 2 times our estimate

Therefor at the end of the story we would expect 3 hours taken to specify what it does, 6 hours to develop it and 9 hours spent testing and developing test documentation.  We use the Task Time to determine this.

We would ultimately like to associate the bug time (debugging task on bug, testing task on bug) to be associated through the Parent/Child association.

A bug being something that was missed or coded wrong, or simply does not work.  We add this as a child association of the story.
This bug then is triaged and given an estimate and 2 tasks.  A debug and a test task.  The time working on this bug does not go back to the parent story on any of the parent story tasks.

Once a bug is finished the development time becomes the Estimate.  So if the developer spends 1 hours correcting the bug, the estimate is 1 hour.

Looking for a report/output like this:



This would allow us to track and plan better our Points and view how much time was on the story and how much time was spent debugging that story. 

I hope this helps explain what we are looking for.

-Jack
















Story
Build a Webform








Estimate
6



Total Time
16




Task
Time



Specification
2



Development
6



Test
8












Bug 1
Estimate
1



Debug
1



Test
0.5


Bug 2
Estimate
1



Debug
0.5



Test
1


Bug 3
Estimate
1



Debug
0.25



Test
1


Bug 4
Estimate
1.25



Debug
1.25



Test
3












Summary
Story: Build a Webform







Estimate
6
point


Specification
2
hours


Development
6
hours


Testing
8
hours







Bugs (4)
4.25
points

[Jack]

Well, that post didn't look nearly as nice as it did in the window I was writing it in!

[Vesna]

Hi Jack

Thanks for  giving your feedback and the detailed case of use.

In answer to your question, whether story estimates are driven by task estimate rollups, the answer is different, and it changes based on the team preference, maturity and methodology they use.

Currently TeamPulse let teams use different metrics for story planning and estimate - like points, and hours - for planning and tracking tasks. As those values not necessary are in same metrics, the roll-ups might not work as expected.

What we plan to implement is to have two values for the Story item. One to be the initial estimate base on the units you use and the other to be Story task estimate – the second one will be a roll-up from all the tasks related to that story and will have an progress bar against it.  This way, both values will be visible and be an object of future analysis and comparison.

As for the bugs there could be a work around by adding task for fixing the bug in the story, so the roll up would included in the unplanned work.

Let us know if the proposed solution will be valuable for you and your team?

Thanks a lot,

Vesna
Telerik

[Chad]

Just to chime in on this thread, YES rollups for bugs would be valuable too in my opinion. Thanks.

[Vesna]

Hi Brian,

Thanks for the feedback. We will consider it for the future releases.
But now the work around for the bugs would be to add task for fixing the bug inside of the story, that way the roll up from the story will included in the unplanned work.


Regards,
Vesna
Telerik