In November 2003, I became the "customer" on an engineering team that was piloting Extreme Programming (XP) as a new development methodology. Despite some difficulties and growing pains, about a year later we were able to release a high-quality, feature-complete application on time. I'll share with you what I learned—particularly about planning. It may prove helpful to other Customers struggling in the wilderness.
XP divides a project into iterations that are one to four weeks long. The work of an iteration is divided into "stories." Each story should add some new business value to the product. My job was to identify a high value set of stories at the beginning of each iteration and do what was needed to help the programmers understand and implement them.
When I joined the team as a technical product manager, marketing had just completed a product requirements document (PRD) for the new application—let's call it Sky. The programmers had produced a proof-of-concept prototype. I was provided with the PRD and access to retail industry veterans, but none of our team had any experience at all in retail supply chain management, whose problems Sky would solve. Oh yeah, one more thing: Marketing had recently determined that Sky actually needed to be a completely different application. Where the prototype had done X with the promise of doing some Y, it would now do much more Y and not do X at all.
So I was the Customer who knew little about the industry, working with a development team that had never had a Customer, to build an application that no one had thought too much about. Great.
Good Thing I Did #1: Identify, categorize, and estimate the features
As I mentioned, we had a PRD to work from at first. Like many marketing documents it alternated between vagueness and specificity, sometimes requesting large swaths of functionality with a single sentence and at other times making detailed recommendations of deployment platform. Snottiness aside, though, the document was complete in many ways—from it, most of what we needed to know could be gathered directly or inferred. It just wasn't terribly accessible. Therefore, the first thing I did was break down the PRD into manageable chunks. I decomposed the PRD into a large set of small features ("featurelets") and organized them into a three-level deep hierarchy. We—the development team, marketing, project management, and I—then had a rather long meeting in which we attached rough time estimates to most of the 500 or so featurelets.
Bad Thing I Did #1: Equate featurelets with stories
It was great to have this finite set of featurelets. We really felt that we'd gotten a handle on the nebulous behemoth, and to a certain extent we had. But there was a problem in moving from definition to implementation. What we had essentially done was encode my way of breaking down and understanding the marketing requirements—the featurelets made sense if you'd read the PRD twenty times but did not make much sense outside the PRD context. Stories need explanation of course, but the problem was how much explanation each featurelet needed and when and how that explanation would occur...which leads me to:
Bad Thing I Did #2: Try to pack it all into the iteration planning meeting
Next came the meeting in which we'd nail down the first real iteration. I had my list of "stories" (still featurelets, remember?) and my testing ideas. I was prepared to explain why the stories were important and why I wanted them done first. I was prepared to give and take and fully expected to scope a few back.
