Speak freely

Bugs effort and time spent is not included into related User story and Feature

The "spent" field on User Story details page automatically sums time spent on the story itself and time spend on any of its tasks.
This could be quite useful, but it does not sum time spent on the associated bugs and therefore it is not the correct value.

70 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Indeed, by default bugs do not affect calculations of effort, time spent and progress of related user stories and features.

It is possible to add calculated custom fields to User Story and/or Feature entities in order to view totals. Here we describe what calculated fields are:
https://www.targetprocess.com/guide/working-with-entities/custom-fields/calculated-custom-fields/

Use the following formulas for calculated fields:

Bugs.Sum(Effort)
- for sum of effort of related bugs

Bugs.Sum(TimeSpent)
- for sum of time spent of related bugs

In far future, new Metric feature will likely be one more available solution. With Metrics it will be possible to define your own custom calculation rules for effort.

(Alex, Support Team)

13 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
  • Alastair Todd commented  ·   ·  Flag as inappropriate

    Just to add to the "this is totally crackers" school of thought.

    Can you not make it an option or something so the 1% can continue to use it as it is but the rest of us can really see the total effort for the Story / Feature?

    Whats worse it effects other metrics too: time left, % late, reporting etc

    Thanks!!

  • Anonymous commented  ·   ·  Flag as inappropriate

    We also would very much prefer if Bugs under Features or User Stories rolled up and effected the Sum of Effort on each.. it doesn't make sense that if a large bug is discovered and needs to be fixed, that this remaining effort would be excluded from the project scope.

    Until this is addressed we are just going to be assigning all our bugs as User Stories and perhaps tagging them. Far from ideal though.

    I don't understand who would want the opposite and why it was designed this way? Why would any company want to exclude bugs from remaining effort on the project?

  • Tom Dean commented  ·   ·  Flag as inappropriate

    The calculated custom fields that are now present work to an extent, but there appear to be much more to do to wrap this up for those users who require time to roll up and forecast inclusive of bugs.

    There are numerous places within the product that they cannot be used sensibly, you can't, for example, create a board for release planning, where releases run across the top and features down the left with the cards being user stories. This is an optimal style of view for dragging user stories into a release and seeing total effort vs capacity for that release.
    As these boards are not as configurable as some of the others, you cannot change the column headers (for sprint/release) to see a calculated custom field totalling the effort in that sprint: http://i.imgur.com/1ApKhIw.png the "5.27 of 53 h done" on this screen grab can not currently be altered to show the arguably "true" roll up of hours for that sprint/release.

    For our use, at least, a preferred method to resolve the "bugs not rolling up" issue, would be to toggle on/off per project if the bugs should roll-up or not. Where the calculations all work based on the toggle being on/off.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I noticed today a discrepancy between what a User Story in TP claims to be the "Time Remaining" and what SHOULD be the time remaining. It seems that the issue is not taking into account the time effort estimates assigned to Bugs. It's only paying attention to the Tasks + Main US Effort estimates. Is this a bug or is this by design? Thanks!

  • Anonymous commented  ·   ·  Flag as inappropriate

    It appears that the Effort of related Bugs is excluded from Feature level.

    I think I will just convert the handful of bugs I have now to US to continue using the out of the box Feature effort calculation, and perhaps shift back to bugs when Metrics are implemented

  • Anonymous commented  ·   ·  Flag as inappropriate

    We compose our releases using only Feature items. In those Features we may have UserStories and/or Bugs. But in the release planning we don't see the the total hours per Feature correctly because it only counts UserStories. Is this a bug in the system? Can we display any other property to see the total number of Bugs AND UserStories?

    Thanks in advance!

  • AdminTargetprocess Support (Admin, Targetprocess) commented  ·   ·  Flag as inappropriate

    As a temporary workaround, it is possible to add Custom Fields of type Calculated to Feature entity.
    Formulas will be the following:
    Bugs.Sum(Effort) - for bugs total effort
    UserStories.Sum(Effort) + Bugs.Sum(Effort) - for sum of effort of user stories and bugs per feature
    Values of Custom Fields are displayed in Feature details popup. Also they can be added as 'units' onto cards on boards or as columns to lists. Use 'View Setup -> Customize Cards' tab for this purpose. (Alex, Support Team)

  • Anonymous commented  ·   ·  Flag as inappropriate

    I'd like to see total effort, effort remain and time spent for all tasks and bugs for each user story summarized together. Into the report with User Stories I've added two summary columns, one for Tasks times sum and one for Bugs time sum. It works well but what i want is that Bugs and Tasks are summarized together. Is that possible?

  • Tom Dean commented  ·   ·  Flag as inappropriate

    Hi TargetProcess

    I am currently working on a project using TP and am trying to track the time spent and time remaining in TP against what we’ve quoted the client.

    What we have sold the client is a number of features.

    Within TP we have mimicked the features we’ve sold the client (as the highest level to track against) and then broken these down further into User stories. This is all fine and working well; I can see the user stories roll up to a feature level, such as time spent and time remaining.

    However, when we identify an issue in testing with a specific story, how do you advise we use the system?

    Currently, when we enter a bug against a user story, and time is spent on that bug, this time remaining doesn’t seem to roll up to the top level of the feature, and therefore I can’t track it to know if the summation of the components that made the feature (feature, use story and bugs) have blown the budget or not as the bug data doesn’t seem to roll up.

    I have seen other systems that give you an option as to whether bugs are counted or not, this would seem to be the ideal solution here I think.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hello Sergey

    I think we have some common ground here, but I have a slightly different point of view. I agree that in some cases one could find the current solution suitable, but I think the general case is not correct.
    Thinking under a UX perspective, your interface does not imply a "loose" relationship between Bugs and Stories but a "container" one. An User Story has a "Bugs" tab and a Bug can be associated to only one User Story. Although you can have "orphan" bugs as well, as User Story is not just "related to" bugs but "contains" them. Therefore, time tracking should reflect this relationship.

    Thanks in advance,
    André

Feedback and Knowledge Base