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.

Vesna

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?

Vesna

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.

Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.