Iteration point-value calculations incorrect
Our velocity calculations appear to have gone haywire since the outage, as well. As you can see from the screenshot, the iteration in which we marked a 50% team strength set that iteration's velocity to 0 points. Several iterations also have a point value higher than the velocity (although within a narrow margin, which may or may not be intended).


1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The company marked this problem solved.
-
Inappropriate?Matt, I'm not sure what's going on with the zero point iteration. Team Strength behaves as expected for me. Once the developers finish putting out the fires from the outage I hope they can respond. Meanwhile can you try setting the Team Strength back to 100% and then restoring it to 50% (when all else fails, reboot!)
To your second question, Tracker arranges stories so that the total points in N iterations -- P(N) -- is equal to or less than N times the current velocity -- V -- while being as close as possible to N times the velocity. (Tracker would be awesome at blackjack ;) The average of your backlog iterations will be your velocity, but any given iteration can have a point total above or below the velocity. Let me give an example:
Say you have a velocity of 10 and every story is 3 points. Iteration 1 (N=1) would have three stories for 9 total points. Using the equation P(N) <= N x V gives P(1) <= 10. The fourth story doesn't fit, as it would mean P(1) = 12. However, Tracker implicitly carries over the remainder. For iteration 2 we get P(2) <= 20. P(2) - the 9 points already spent in Iteration 1 gives 11 points to spend. Iteration 2 will still have only three stories for a total of 9 points, since the fourth story means 12 points in the iteration.
Now we get to Iteration 3. P(3) <= 30, therefore P(3) - 9 - 9 <= 12. Aha! Now we can fit four three point stories into the iteration, and so Iteration 3 will have four stories for 12 total points. Here the cycle would repeat.
As you may have deduced, it's possible for any given iteration in the backlog to contain points in the range V +/- (A - 1), where A is the highest point value story in your project (3 for linear, 8 for powers-of-two and fibonacci). The proof is left as an exercise to the reader.
I’m like I'm back in algebra class
1 person says
this solves the problem
-
Inappropriate?Yup - it looks like waiting a night and rebooting the browser actually brought that 0-point iteration back in line.
Thanks so much for the explanation - that makes total sense, now.
I’m happy I still understand math
-
Actually, it looks like resetting the team strength to 100% and then back to 50% still results in a 0 point iteration, although I think I've determined what's happening. The story that is next in line has 8 total points, but my team's current velocity is only 14. When I set the team strength to 50%, it prevents this story from moving into the iteration, effectively blocking the stories behind it. Does this sound accurate?
Of course, this behavior has helped me notice that I clearly need to prioritize my stories differently, as I don't want my team to tackle a story of that complexity with 50% strength. So this, as well, is likely the intended behavior.
Thanks for the great product and service. -
Inappropriate?Matt, your analysis is right on the money regarding the 8 point story and the 7 point velocity iteration.
Loading Profile...



EMPLOYEE