planning xp

July 28, 2009

I enjoyed reading Planning Extreme Programming by Kent Beck and Martin Fowler. I found the book to be an easy read and finished it in just a few days. Beck and Fowler are generous in their on-line writings and you can find a lot of information about agile process in various articles; however, I found it to be very useful gathered together in a narrative that clearly spelled out basic principles and best practices. One point that they made toward the end of the book was that you can borrow any of the practices individually, but that XP works best when the different practices are combined in a process that reinforces itself. They weren’t speaking of development practices, like pair programming, but planning processes, such as:

• A clearly identified product owner who communicates directly and regularly with the development team
• Iterations, where the date never slips (only the scope if needed)
• Planning with yesterday’s weather technique: you only promise to deliver as much as you did in the last iteration
• The product owner writes stories (e.g. short sentences on index cards)
• The people who will write the code make the estimates
• The product owner meets with the dev team at the beginning of each iteration and communicates the stories, answers questions, clarifies details
• The development team breaks stories into tasks (detailed estimates are then given to the tasks without reference to previous estimates)
• If you aren’t going to get everything done in the time available, then you reduce scope by talking to the product owner and letting him or her prioritize, including breaking larger stories into smaller ones that will fit. (This should happen rarely)

They made the point early on that if you aren’t working in an environment or with a client who is willing to have a product owner regularly spend time communicating with the engineers and involved in the process, don’t bother with XP at all. I admired this strong stance, and agree that the whole thing falls apart without an individual willing to make business decisions and spend some time refining requirements and prioritizing.

I’ve been practicing many agile processes since before the terms XP or agile were coined; however, I appreciated the focused perspective and am planning to try the process as described (which is not very far from my typical process). I do have a few questions not addressed by the book:

• Is there a way to use “yesterday’s weather” as a planning tool if you are working with elastic resources? (e.g. volunteers who work different number of hours per week or in a bootstrap startup environment where people are working variable hours) if you have a more laissez-faire approach to milestones, then having simple priorities rather than well defined scope for each iteration seems to make sense to me. Would Beck and Fowler consider this an abandonment of XP or a fair variation?
• What are effective ways to handle the planning process when this week’s stories have unexpected complexities? (e.g. the product owner describes the story, the developer asks some key questions which require a decision, the developer wants a decision on the requirements, but the product owner needs to understand the consequences of the decision before deciding) My approach to this is defer the story and allocate some time during the iteration for design/brainstorming sessions on the challenging story.
• When does the UI design happen? I have a number of answers to this one, but was surprised that I don’t hear this more frequently addressed in XP.

---

Comments

Jamie Flournoy July 28, 2009

I consider myself an XP apprentice on the cusp of becoming a journeyman, definitely not an expert but not a n00b either. :)
So here are my thoughts:

Question 1 (variable scheduling): If you estimate user story effort in terms of pair-half-days = 1 point, then you should be able to use that against the fluctuating schedule of the team to guesstimate how many points/week your velocity will be. If you actually can't predict when your team will work at all, then estimation seems to me to be impossible. In that case maybe you just decide that each iteration ends after 10 points or 2 weeks, whichever comes first.

Question 2: If possible the customer should be included in planning meetings so you can have that conversation in real time. You should also have a list of upcoming, roughly prioritized future stories so that you can look ahead and see whether your higher-effort design is going to save you time.

See also my blog post on "lazy YAGNI": http://www.pervasivecode.com/blog/2009/05/30/xp-experiences-part-2-of-5/

Question 3: I have found nothing at all about UI design in particular in XP writings. I prefer to assume that this is part of what is means by XP "design" along with the more obvious code & DB design. You do design when it seems necessary. Avoiding the misinterpretation of YAGNI as "lazy YAGNI" helps here too: if you know what features are coming up 2-3 months from now, that helps you design a UI now that will have a logical place for the future features to fit into.

Hope this helps!

Alf Mikula July 28, 2009

In response to your first question, I've struggled with this one myself. Obviously if you can't control how many engineer-hours go into the product, fixed iteration length is a little harder to deal with. I think in this case you either 1) Pick a constant size estimate (use something like story point estimation and planning poker) and close the iteration when the work is done, or 2) Pick a constant iteration length and release what you have at the time.

As for effective ways to deal with unknowns, I like to use story point estimation with Fibonacci values (1,3,5,8,13) and bump up the estimate (3 -> 5, 5 -> 8) when there's a minor unknown, to compensate. If there's a major unknown, we try to defer the story and allocate time for research/planning like you suggest.