A couple days ago in my “What happens when an agile team falls flat on their face?” post I talked about how last week we failed to deliver on our commitments. In the comments of that post Howard asked “
Doing one week iterations can be tough. They leave very little room for error and place a lot of pressure on the development team to perform well each and every day. Throughout the course of our project we’ve tried a bunch of different things to help ensure we meet our commitments and know when things are going off course. While we’re no-where near perfect I think we do a very good job of identifying what needs to be done within our iterations as well as tracking our progress throughout the week.
At the beginning of each week business puts on a demo for others within our organization as well as a few select clients. This allows everyone to get a feel for what was done the previous week and provide feedback on what they like, and don’t like. Not meeting commitments for an iteration makes the process of giving the demo difficult since it is glaringly obvious to everyone involved when things weren’t quite finished. Fun times!
Following our iteration demo we go into a retrospective where we talk a lot about the previous iteration. We identify “memorable moments” and classify them into several categories (enjoyable, frustrating, puzzling, more of, less of, same of). As a result of this process we’re able to identify areas that we need to take correctionary action, as well as areas where we’ve improved. The retrospective is a vital part of our process as it ensures we don’t fall into a rut and struggle with the same issues over and over. In short it helps us be crazy-agile.
After completing our demo and retrospective we start talking about the stories we have planned for the next week. Par the course, business always has more stories then we can fit into a week. From a development perspective we need to ensure we can complete the stories we commit to. Since everyone is always going to want development to be able to go faster and complete more stories in a shorter time period its important that we don’t commit to too much (or too little). If nothing else we need to be consistent with our estimates and reliably deliver what we commit to.
To determine the number of stories that we should breakdown into tasks we look at our previous iteration velocity (aka “yesterday’s weather”). Using yesterday’s weather provides us with a starting point for our story breakdown. While it’s nowhere near perfect it helps get us started with the approximate number of story points we’ll be able to complete in the coming week.
Once we’ve identified the approximate number of story points we break each individual story into tasks. This has proven to be a critical part of our process. This past week during our retrospective we realized that we did a piss poor job during our task breakdown last week. We had about 15 task cards on the board for last weeks iteration while this week (which is just the completion of our previous weeks work) we have 40+ cards on the board. It goes without saying that we didn’t identify a lot of work that was required for the story.
After breaking down our stories into tasks we estimate each task. Over the past 12 weeks each member of the development team selected cards that they felt they could estimate and did so. To try something different this past week we estimated the tasks as a group using “poker estimation”. Once we have estimates on all of the tasks, as well as cards for all the non programming tasks that happen throughout the week we add everything up to see if everything will fit within the available time. More often than not we have more work than time available so business goes through the difficult process of prioritizing stories and figuring out which they’d like to fit into the iteration.
After the stories are selected by business we place the cards on our large magnetic whiteboard. Story cards go from top to bottom on the left hand side of the board and task cards go from left to right across the board. When we start a task we grab the card off the board and mark it as started with a brown marker and our initials. When a task is completed it is marked with a green marker and the amount of time spent on the task is placed on the front of the card below the original estimate.
By marking our cards with brown and green markers we’re able to see how we’re progressing through the iteration. If by Wednesday afternoon half the board isn’t green we start to determine if we’re going to need to cut tasks or stories from the iteration. As mentioned earlier this is where task breakdown proves to be key. If we’ve done a lousy job of breaking down our tasks we may get a bad read on how we’re progressing. If on the other hand we’ve done a good job of breaking down our tasks then the board gives us a perfect read on where we are with things.
Of course we never have and never will be able to identify every task at the beginning of the week. As new tasks are identified we create new cards with an original estimate of 0 and an Updated Estimate of whatever is appropriate. In previous iterations we would place the new tasks on the board along with the original tasks, however, for our current iteration we’ve decided to track our new task cards by putting a yellow line above the card on the board to ensure we don’t get a false sense of progress. If we’ve completed 25% of the cards on the board but all of those cards were new task cards that could be a sign of trouble.
As we get towards the end of the week we begin to get bug reports from QA. The bugs are placed on index cards and put up on the whiteboard with all the original tasks. The cards are typically separated into a “bugs” section on the whiteboard. “Bug” tasks are handled the same as normal task cards except for when they’re very small in which case they usually get combined into a single card for time tracking purposes.
We follow the above process which does a pretty good job of ensuring we don’t have weeks like last week. When we do have a bad week the process is there to ensure we do the things necessary to prevent it from happening again (hopefully). What do you do to help increase your likelihood for success?