Iteration Planning Meetings
April 17, 2014
During my novice apprenticeship, my iteration planning meetings (IPMs) with Rylan typically consisted of some code review, conversation, and high-level scoping out of tasks for the following week. As a resident apprentice, however, our IPMs are becoming more formal and will increasingly resemble the IPMs the craftsmen have with our clients. IPMs are crucial for consultancies like 8th Light—they are the primary interactions between the two parties working together, not to mention being directly concerned with the always-important issues of time and money. As someone who has always valued honest, transparent communication, I look forward to developing my ability to explicitly define and describe my work, and estimate its value, over the course of my residency at 8th Light. Here are some thoughts about keeping IPMs productive and valuable for both sides.
Know Your Personnel. There are big differences between presenting your work to a software engineer, a VP of marketing, and a CEO. I had heard from another apprentice that each “story” (a basic unit of work—similar to “user stories” or “features,” though ideally not as broad as those sometimes are) should be demo-able, in order to demonstrate to your client that the work has been completed. However, what’s demo-able to one person may not work for another. For now, Rylan acts as my client, and therefore I can use passing specs to demonstrate the completion of some stories. However, someone less fluent in code wouldn’t necessarily be convinced that certain requirements have been met simply by green text in a terminal window. The audience members at IPMs are taking time out of their days to meet with you—don’t waste their time with material appropriate for some other group. Make sure the content of your demonstrations and talking points are tailored appropriately.
Keep Stories Focused
As I mentioned above, my earlier stories with Rylan were often pretty high-level goals, but more recently we’ve focused the stories on more specific objectives. Each story has “acceptance criteria,” which conceptually is pretty self-explanatory, but can easily be written poorly. Well-written acceptance criteria often have a behavior-focused style that (conveniently) often lends itself easily to demonstration: “Given an empty board, When I select some spot on the board, Then the board should update with my token in the selected spot.” As an added bonus for us developers, acceptance criteria can be written in a way that helps direct TDD as well. Stories get translated into tests first, and then the code is written to pass those tests. As with test suites, the more explicit you are when writing acceptance criteria, the more sure you will be of what you’re working on and what needs to get done.
The temptation to “cowboy” is strongest at the beginning of a greenfield project. When I started my Clojure TTT last week, I wasn’t quite sure where to begin, but I could think of various functions I knew I would need, so I just began building some namespaces fairly haphazardly. This is not how we want to structure our development process, though, and we should avoid getting off on the wrong foot. We want to have a plan in place that is clear to both ourselves and our clients.
A great way to avoid unstructured work at the beginning is to be sure to include every step involved in the project at the IPM. This can include things as basic as “install Leiningen,” “generate a new project using the Speclj template,” and “set up a repository on GitHub.” It may seem like overkill to mention these things, considering they generally happen for every project, but there are two major benefits to doing this. First, by writing out the true first steps of the project, you get in a planning mindset and start thinking of the immediate next steps (the first steps of coding) to better define the path ahead. Second, you’re providing more, better information to your client about what all you are doing for them. No smart client is going to complain about having too clear an understanding of where their money is going.
Estimating points for time and value of stories is the hardest part. Human beings are terrible at estimating. Nevertheless, it’s something clients need in order to manage budgets and timelines, and we therefore need to take it seriously, try our best, and get better at it. At 8th Light, we provide three point estimates: optimistic, realistic, and pessimistic. Last week was the first week I’ve had to assign estimation values for Rylan, and it was very difficult, so I don’t have too much great stuff to say here, but I do have some tips:
- The three categories don’t necessarily have to increase from one to the next to the next. If you’re confident something won’t take longer than a certain amount of time, there’s no need to arbitrarily add points to the “pessimistic” estimate.
- Be confident. It’s easy to overestimate how long something will take. (Of course, it’s easy to underestimate too… we’re terrible at this estimation thing!)
- Be honest. Don’t take advantage of the client by inflating the difficulty or time required for some story since he or she might not know any better.
- Points relate to time, but also to “value,” which is a little less hard to define with precision. This is something I’m definitely still working on understanding. It’s hard to compare stories to each other and estimate which will take longer to complete, let alone compare them on the basis of value.
Be a Professional
So much of professionalism boils down to respecting your client. Arriving well-prepared with a plan, communicating openly and honestly, and listening carefully are key to successful IPMs and, by extension, building strong relationships with your clients. These are not new ideas to me, but I recognize their value and am glad to have the opportunity to practice improving them with people who also understand their importance.