How the Estimated percentage is calculated in a Formal project when plan items(Business Need WI) is involved
In RTC 3.0.1.4 or any version of RTC(tested with RTC 301 and 4.0 as well) Using Formal project management process based PA, I add task or task+defect to a Plan, all progress bar will show 100% estimate.
If I added Plan items Business Needs work item, the progress bar on the complexity will become 50% now, this seems that Business Need WI is a part of estimated calculation. However, the Business Need WI itself shows 100% estimate. If both task and Business Need WIs are 100% estimated, why the total is not 100% but 50%?
It seems that Plan items is mattering here. Uncheccking Business Need as plan items and check the Plan view again. This time the complexity progress bar is 100% but time progress bar and group user's progress bar will show 50% instead. The result is confused.
|
One answer
|
By default there will be no complexity attribute defined in the out of box formal process template.
There are 2 major problems with the way the the formal template might be used.
1. The complexity attribute might be set to the some Enumeration due to which the complexity based progress bar is not giving the warning.
2. In formal project planning the complexity attribute is not used for the planning its mostly the hours. The progress bar they are seeing is the one based on the complexity attribute.
If you are planning to use the hours for all the work item types then the Complexity based progress bar is not of any use for them. You can ignore that progress bar. I agree that there should be a configuration through which this bar can be hidden if the customer is not using the complexity attribute at all. Ability to hide the Progress bar based on the Complexity attribute in Plan Details. (227919) is the Enhancement for this problem.
From the formal project management perspective the progress based on the complexity attribute does not make any sense. As the planning itself is not done from the complexity attribute perspective. The correct usage of complexity attribute is for the high level estimations. Ideally the Complexity attribute will be the Enumeration or Integer.
If needed you can create a new custom attribute of type integer or Enumeration. Enumerations are better as they can standardize as small, medium or large ...
This is the correct usage of the Complexity attribute. Though setting the Time spent or Priority as the complexity attribute is not blocked it will not help in using the feature better.
If the Customer is using the Enumeration then the IDs of the Enumeration values should be integer. You can refer to the story points Enumeration for this.
The simple rule is what ever attribute they set as complexity, if they want that attribute to be considered as Estimated then the value of that attribute should result in a number greater than 0.
I do not encourage using the Estimate and Time Spent as the complexity attribute as they are Duration attributes and their values will be stored as Milliseconds.
The business rules to consider a work item to be Estimated or not is very simple.
For the progress bar based on the hours the Plan Items are assumed to be estimated irrespective of weather it is estimated or not. This behavior of considering the plan items to be estimated in the hours based progress bar is under discussion. Of we create a Plan Item then the hours based bar should or should not consider it for the calculation of Estimated % is something debatable, but this is the current behavior.
For Progress bar based on complexity attribute
The plan first checks if the complexity attribute is defined or not. If it is not then it will not draw the bar but displays the message.
After the first check the plan gets the complexity attribute for a plan item, checks if it is numeral and checks if its greater than 0. If so then it will consider that work item as Estimated.
|
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.