It's all about the answers!

Ask a question

Percent Estimated calculation has changed since upgrade - where are settings?


Mike Shkolnik (9808161143) | asked Feb 27 '13, 1:21 p.m.
Previously the "percent estimated" - the number to the right of the progress bar at the top of a plan - was based solely on the % of Tasks estimated (in hours). Since the upgrade from 2 to 4, this has changed. The % now also takes into account the % of Stories with Story Points. I like this. One problem - it also takes into account the Epics, which have no weight associated with them, thus each Epic lowers the % estimated. Is there some way I can tell RTC not to count Epics in calculating the % estimated? Otherwise a once useful number is now useless...

Comments
Mike Shkolnik commented Feb 27 '13, 1:38 p.m.

Just to be sure, I checked the "Types and Attributes" configuration for Epics and there is no Story Points attribute.

One answer



permanent link
Millard Ellingsworth (2.5k12431) | answered Feb 27 '13, 3:14 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
There is a defect here, being tracked by https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=193444


Comments
Mike Shkolnik commented Feb 27 '13, 4:04 p.m.

I am specifically referring to the handling of Epics in the top-level progress indicator, which is not addressed in that work item.


Millard Ellingsworth commented Feb 27 '13, 4:29 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER

You are certainly welcome to add that case just to make sure it gets covered. I expect the issue would be automatically addressed as they are both Plan Items and the crux of the problem seems to be counting the "container" for the children (so all child work items are estimated, yet 1 of N, the parent, is not, so you can't get to 100%).


But I can see where counting epics when they are children could be problematic (since they can't carry an estimate at all). What are your expectations in that case? If you have a parent epic with 3 children that are epics should the percent estimated be 100 (because estimating is not possible)?

The other issue here in the larger context are other work items that can't be estimated: Impediment, Retrospective, Adoption Item.


Mike Shkolnik commented Mar 04 '13, 8:06 p.m.

Any work items that have no "weight" simply should not be counted at all in figuring out % estimated. No hours or story points? Then it should not be counted. Counting it as 100% wouldn't be right either as it would throw off the number. If you have 5 items with no estimate and 5 items with no weight, it should not say 50% estimated when in reality nothing is estimated. In that scenario 0% estimated would be correct.


Mike Shkolnik commented Mar 06 '13, 2:41 p.m.

This is more broken than I thought.
1. Because unweighted items are counted, as you mark weighted items complete, the estimated % goes down even though you haven't changed any estimates.
2. Story Points estimated % is broken in plans that use an extra level, such as "Marquee Feature". Both the story points completed at the top and the story points you see by hovering over the estimate do not show at all in these plans. Plans that only go to the epic level do show the numbers for story points.
3. Upon marking all items complete (closing out the sprint), the estimated % for stories and tasks become "--" instead of a number! This happens regardless of the actual estimated %, thus if you had marked items complete that were never estimated, that is now a secret you can only discover by manually looking at each work item estimate in the closed sprint.

Again, I like that story points are now included in % estimated, but they really broke things in adding this feature.

I have added this info to the enhancement you linked to, though clearly the problem is much bigger than what's listed in the summary of that request.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.