Expected cannot exceed 100 initially

[andreas.schroeder@…]

Initially, without having any tickets assigned to a milestone, the expected value can't exceed 100, and it also can't exceed the maximum of the intial hours left (i.e. on the first day) of all tickets. This isn't a big issue, but the limit of 100 seems arbitrary :)

The example below was created with the following settings and no tickets associated with the milestone: [[BurndownChart(milestone=Iteration 1, startdate=2010-05-03, expected=192)]]

[andreas.schroeder@…]

fixing the severity...

[osimons]

I haven't seen the details of this code, but looks like a similar issue to what is seen in the XmlRpcPlugin where queries just return a fixed number of tickets. This number is tied to the paging of web queries, and is a trac.ini config value. You can also override it on individual queries by using 'max' argument - like max=500 or similar.

[anonymous]

Replying to osimons:

I haven't seen the details of this code, but looks like a similar issue to...

Browsing docs and the code, I see that that this can't possibly be related... Trying to help based on a quick hunch, and instead I just end up making noise. Please ignore :-)

[François Boissonneault]

mmh, it seems it's related to the number of hours calculated in the milestone. If, per example, I have 345 hours in the milestones, it seems I can't make expected higher than this. Can you guys confirm the problem is the same?

[andreas.schroeder@…]

Yes, that's exactly it. If your max hours is at 345 and you set expected to 500, the burndown's "left hours" axis will cap at 345, and the expected line will start at 345.

Btw, we had milestones with far less than 100 tickets and still got this capping problem with expected hours, so I don't think that it's related to a ticket-max cap.

[osimons]

Fixing scaling of Y axis when expected value exceeds maxhours.

[osimons]

attachment:t7003-expected_y_axis-r8886.diff​ should fix this issue. Most of the patch is unittest and test infrastructure, so the only line that in the end needed changing was this:

estimationtools/burndownchart.py

@@ -248 +248 @@
         dates = timetable.keys()
         dates.sort()
 
-        maxhours = max(timetable.values())
+        maxhours = max(timetable.values() + [int(options.get('expected', 0))])
 
         if maxhours <= Decimal(0):
             maxhours = Decimal(100)

Anyone up for testing the patch before I commit?

[Ryan J Ollos]

I can test with Trac 0.11.7 by end of day tomorrow. I haven't used this plugin before, but was planning to install it soon anyway.

[osimons]

(In [9029]) EstimationToolsPlugin: Fix issue with Y-axis scaling when 'expected' value was higher than any max value for hours. Tests included. Closes #7003.