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. I couldn't wait to inscribe these wonderful stories on that eagerly waiting blank slate of a development team.
Well, a lot happened before we finally called off the meeting. To summarize, I scared/annoyed the daylights out of the developers by laying out much more work than they could do in an iteration. (Our earlier estimates were consistently too small.) I asked for a collection of features that made very little sense from an implementation point of view, gave too little detail about some features, and inappropriate implementation advice on others. Finally, after four hours of back and-forth in the conference room, we ended without any clear consensus of what the developers would start—when they recovered from the meeting.
I left the meeting with a strong sense that the developers were a petulant, nit-picking herd of cats with a deep fear of what was to come. I had tried to conduct an iteration-planning meeting according to what the literature and our consultants said was the "real" XP way, and it had gone abysmally.
After a bit of reflection, I concluded that the developers had no idea what I was talking about, and it wasn't their fault. Extensive discussions, clarifications, restatements, rat holes, etc., in our free form iteration planning had left us all tired and confused. I also had to admit to myself that I had a tenuous grasp at best of the retail subject matter. So what to do in such a situation? Well, how about:
Good Thing I Did #2: Focus on context
We essentially gave up on the first iteration. The team stayed busy working on tasks parceled out by the development manager. For the next iteration I decided to make sure the team understood what I was asking for and how it fit into the grand scheme of things. I picked a set of logically related features and used an "info sheet" to describe them as a whole. The info sheet is a short, one- to three-page document with plenty of pictures (diagrams, callouts, and, most importantly, mock screen shots). It describes the important characteristics, behavior, and logic around a coherent set of features. It is written informally—for developers only—with no official signoff, and does not attempt to be an authoritative, all-encompassing specification. Instead, it is a device for communicating the current thinking about a piece of the application at that point in time. It is also the central organizing item for:
Good Thing I Did #3: Start pre-planning
The info sheet is a great way to communicate the context around a logical set of features, but it isn't a story or set of stories. Given my lack of success in a large group iteration planning meeting, I guessed that a smaller group might work better. The result was what we eventually called the pre-planning meeting. In it, a development pair, a tester, and I would review and discuss (often animatedly!) an info sheet and cooperatively develop stories that moved us toward the ultimately desirable functionality described by the info sheet. Because the info sheet described a bunch of related functionality, the development pair and the tester were able to focus their energies on stories that revolved around a specific theme, which often spanned iterations. The small group discussion format ensured that all parties understood the business purpose of the stories and the technical issues required to implement and test them.
A Note About Environment
A risk of the info sheet/pre-planning process is the development of silos of knowledge. The focused, theme-based process spared developers lengthy debates about stories they'd never work on but didn’t necessarily promote whole-team ownership of all areas of the application. Although we struggled with that throughout the release, we were fortunate that our physical environment helped mitigate the risk. The entire release team—developers, testers, the project manager, and I—sat together in a "pod," an open area with one big conference table in the middle. Informal communication occurred daily as we participated freely in discussions and problem solving on just about every topic related to a software release. Ample cross-fertilization occurred because the space allowed the team to communicate informally when interested, kind of like ... humans.
So, what did I learn in the nine months between that first abysmal iteration planning meeting and a high-quality, on-time release? It is all about communication. Period. By finding ways to promote natural—bi-directional, iterative, informal, multi-modal—communication that leads to a growing body of shared knowledge, we actually were able to optimally balance my understanding of what the product needed to be with the development team's understanding of what was possible. If we can do it, you can too.
Planning an iteration
We executed the following sequence once per two-week iteration:
Pre-planning (repeat for each trio, each pre-planning meeting lasts 1-1.5 hours):
Iteration planning (meeting lasts 1-1.5 hours):