Day 46 - The Process

Things are progressing very nicely on our project. This week we had our first end of iteration demo for our client. We had a shorter than usual iteration (We want our iterations to start on Wednesday and end on Tuesday, but this one started late on Thursday, effectively making it a two day iteration), so we had a limited number of things to show them. However, what we did showed them pleased them greatly, for a first meeting it went about as well as it could have.

For those of you unfamiliar with software development, here's a relatively quick explanation of what an iteration is, and why we do it. An iteration is a set interval of time (usually 1-2 weeks) in which we commit to delivering as much functionality as we can in that period of time. We also break down those pieces of functionality into something called User Stories.

A user story is simply a way of describing a feature as seen from the User's perspective. So if I want to design software for an ATM, one of my features might be around being able to withdraw money. My story would end up beginning something like this "As a user, I want to be able to withdraw money from my checking account". A client generally won't see much return on features that don't improve the experience of the user. Framing a feature from the user's perspective helps ensure that we're always working toward something that will benefit them.

A User Story also describes what determines that feature being complete, we call that its Acceptance Criteria. These can vary in complexity based on the feature in question. Going back to my previous ATM example, one Acceptance Criteria for it could be that "Withdrawing money from a checking account updates the balance". You surely wouldn't want to call that feature complete if the withdrawal process wasn't actually withdrawing money from the customer's account!

If a feature is very large, we refer to it as an Epic. If we have an Epic, we try to break it down into multiple User Stories. We never want to have a user story that is too large to complete in a single iteration, and ideally we'd like them to be small enough to complete in no more than a single day. I'll get to why that is in a little while.

Before we start each iteration, we take a look at the Backlog. The Backlog is a collection of all the user stories we have to complete before we can say that we're done with the entire project. So we go through the Backlog and pick out the ones we believe can finish in the upcoming interval. At the end of each iteration, we have a meeting with the client to show them the features corresponding to the stories we finished.

The real purpose of that meeting is to get feedback from the client. We want to ensure that they like the way we implemented the features we completed in that iteration. A lot of customers don't really know what they want until they see it in action. This is why our iterations are as short as they are. We don't want to work on something for months only to find out that we didn't get it done the way the customer wanted. Having a short feedback loop is critical to delivering software that the customer is happy with. It makes things less risky for us, and ensures a smoother working relationship with our client.

So this kind of turned into a mini-primer on most of the things that encompass agile software development. This would probably be a pretty boring read to anyone who's already familiar with it, but hopefully it wasn't too terrible for those of you for whom this was new information.