Ats Planning Game

Part of AtsGoesExtreme and the AtsDiary. See also PlanningGame.

The AtsPlanningGame had to diverge from the standard PlanningGame because we were picking up a project that was already in production, had been abandoned for a short time (six weeks), and then picked up by a new team to implement the last iteration's features. As a result, our AtsUserStories were all less than a week of ideal time.

The day before the day we were scheduled to have our PlanningGame, we were told to prepare a number of schedule estimates based on different personel configurations so that management could make a time-critical decision about whether or not to keep two of the four developers. We still had a number of medium and high risk AtsUserStory estimates (about 50%) and of course we didn't know which UserStories would actually make it into the iteration.

Since we didn't know which UserStories would be in the iteration we could have simply added them all up and presented that as a planning estimate. But seeing an estimate of (say) four months when management was expecting 4-6 weeks would have caused major problems. So we decided to take the subset of stories that was in highest demand, security, along with all of the known bugs, and simply estimate those. Then when we presented the estimate, we emphasized that this was just the security requirements and that in Monday's PlanningGame meeting management could proscribe a certain number of available hours and the customers could decide for themselves which additional stories would be developed within that time frame. Of course, the customers could just as well decide not to do security at all, but we didn't mention that. It's also not very likely.

We estimated the stories in IdealHours?, but we did not present the results in that form. I don't want to have to explain to a skeptical management the difference between an IdealHour? and a RealHour?. Instead, we just added up the stories ourselves, applied the various loadfactors for the various personnel configurations, and presented the final totals. This went over without a hitch, in my opinion because management doesn't care about load factors and the details of software estimation; they just want to know how long it will take, and what their choices were.

We presented three different answers: One for four developers (the original plan), one for three, and one for two. In each one of these configurations, the number of IdealHours? remained the same, but the AtsLoadFactor and RealHours? changed. Here's our results. The AtsLoadFactor was a purely estimated, since we haven't started coding yet. I've heard mention of using SpikeSolutions to help estimate load factor, but I don't know how we could do that, since we are doing the AtsSpikeSolution(s) as research activities in order to determine what our estimates are in the first place.

For the curious, here's our results:

 Ideal Hours: 170     (53% low risk; 12% medium; 35% high)

 People   Load Factor   Hours   Weeks
 ------   -----------   -----   -----
    4         3.5         149   ~4
    3         3           170   ~4.5
    2         2.75        234   ~6

Since we weren't done with our AtsSpikeSolution(s) when this request came down the pipe, the IdealHours? estimate that this is based on is uncertain. In retrospect, I should have presented the results as a range to account for that uncertainty. +/- 25% would have been about right, I think.

Oh, and I never mentioned the term "PlanningGame." ExtremeProgramming uses attention-grabbing names, but ones that are very hard to sell.

When we held the actual PlanningGame meeting, there were representatives from three user groups present. Two of these groups had very similar goals, but one group did not. At the beginning, this led to some delays (it took us ten minutes to get through the first four cards), so I instituted a "conflict pile" to go along with the high, medium, and low priority card piles. The rule was that, if there was any disagreement about a card, it would go in the conflict pile and be discussed in more detail later.

If I were to do it again, I wouldn't use a conflict pile. Instead, as with estimating risks, I make the rule that anybody could place a card in a pile, and anyone else could move a card to a higher pile. That way, everybody's needs could be satisfied quickly. Then, when discussing individual iteration schedules, the cards could be discussed in more detail, but high-conflict but not high-priority cards wouldn't take valuable time.