Today we had a categorically bad Iteration Planning Meeting for our internal project. The IPM is a weekly meeting where we show the client the work we completed for the stories we said we would do.

We had committed to completing four stories of moderate size. The team had completely finished one, but the other three were about 95% done. The problem is that ANY remaining percentage point from a story being 100% finished means that the story is not done, and when we’re demo-ing to a client we need to be 100% certain that what they asked for is implemented, tested and meets their acceptance criteria. Anything less than that leaves us with something like “well, once we get this code here then the app will do this…” or even worse “it shouldn’t do that, but we’ll fix it…”

On top of the incompleteness, with all of our time and energy focused on the move on Friday and our conference room equipment packed away in various boxes until about 45 minutes before the IPM, we were completely unprepared from a technical standpoint for the demo. We hadn’t discussed how we were going to show the app off to the client and hadn’t spent any time on Friday making sure that everything was running smoothly for a Tuesday morning meeting. In hindsight we should have taken just a few minutes on Friday afternoon to either prep for the demo or contacted the client and explained that due to the move we needed to push the IPM to Tuesday afternoon or even Wednesday morning.

Paul sat in on the IPM as one of our clients and rightfully called us out. The demo, by all accounts, was an embarrassment. The technical hiccups coupled with partly finished stories should have never been something that we would want to show off as examples of our workmanship.

So, a few rules to come out of today’s lessons:

1) There should be a code freeze at some point the day before the IPM so that you can run through the demo at least once.

2) Figure out the technical requirements of the demo: is the client local or remote? Which machine or staging server will you use for the demo? Then during the practice run make sure the demo goes off without a hitch on that machine.

3) Everyone on the team should touch base the day before the demo. Does everyone on the team agree the stories are done? Does anyone have any concerns about any of them?

[There are only five of us on this project and we have daily stand-ups, however, the move and the holiday weekend threw us off our rhythm. We went into the demo and it had been a full five days since we’d touched base! ]

One other important lesson for me was to work closer with our designers. We have a well-versed design team and there’s no reason we shouldn’t pull them in to take a quick look at any initial layout we might start building for a page. They can make suggestions and help guide us along during the process. A little polish goes a long way during the demo.

It might be unrealistic to think that every IPM will go perfectly, but if one doesn’t then it definitely shouldn’t be due to a lack of proper preparation on our part. I’m looking forward to next week’s.