We played a game based on the description of Zhong Zhi provided here. Had three teams. Two finished quickly; the third took considerably longer. This game is simple: no set up, no long discussion afterwards. teaches rather quickly that if we each go our own way, work will be duplicated and some work missed, but if we communicate and collaborate, we can produce as a team what no one can as an individual. we scheduled it at the beginning of the workshop to get people moving and talking.
Measure & Improve Quality
QA1-Skip 110000APC2 393 Visits
Okay, let's assume we estimate work items using a brief Fibonacci series. (0, 1, 2, 3, 5, 8, 13) Why use this expanding interval series? Uncertainty with respect to size varies directly and geometrically with size. In other words, we are pretty good at estimating small things and less precise about estimating large things.
So we enter a sprint (iteration) with work items sized 1, 1, 3, 2, 1, 8, 8, 5, 2. We expected to complete all of these, which sum to 31 points (or ideal hours or whatever).
As the sprint proceeds, we burndown these items: 5, 8, 3, 2, 1, 8, 1 and then run out of time; those sum to 28. We had two additional items (sized 1 and 2) which were planned but not completed. We worked on the size two item but didn't finish testing it. We did not start work on the size 1 item.
So what was our velocity during that sprint? Some might argue that the team should get partial credit for working on the size 2 item which was not fully tested. Most current practitioners (and I) would say anything not tested is not completed. Only the completed work counts, and those add up to to 28, so that was our velocity. I think 28 is too exact.
According to our series, an eight could have represented any value between 6.5 and 10.5, a five any value between 4 and 6.5, .... And the range for any value overlaps its predecessor and successor (ranges are not mutually exclusive). So the metrologist on my shoulder argues that a set of ranged values cannot be summed to a point value. The actual velocity of our team was something between 22.5 and 37. I would personally call it "between 25 and 35."
So what? Isn't this overly complicating something which is really simple? My point (pardon the pun) is that we are dealing with imprecision in original sizes, so let's keep that imprecision in any statistic derived from those sizes.
Here's the practical aspect:
if we are tracking velocity manually, use 28 but call it "about 30" and don't lock our team into trying to fit exactly 28 points into the next sprint.
if we are using an automated system to track velocity, let the computer provide a ranged value for velocity and ask the team to find a place inside that range when planning the next sprint.