Motley says: “Just build the features, and they will come. Who needs a goal?”

Summary

______________________________

Motley: Well, Mave, another successful 3-week development iteration. We delivered some great stuff - of shippable quality - and are off on and running on the next one.

Maven: That's great! What does "successful" mean for your iterations?

Motley: We finished the work we set out to do, of course. We had very few bugs reported by the test team, so I would call that a success.

Maven: Was there a theme for the iteration? How did you determine what work items to include during your iteration planning?

Motley: Just a mish-mash of work - no real theme. Why do we need one, anyway? As long as we make progress on the software, that's all that matters.

Maven: Having a team goal for the iteration allows the team to rally around a common theme. It also allows you to decide on features to work on during planning and more quickly build complete segments of the product. Instead of finishing very small pieces that do not add up to any real functionality, you get the team working on just a few small pieces, with everyone pitching in to complete those by the end of the iteration.

Motley: What are you suggesting? We pick a goal during iteration planning and all march toward it like ants?

Maven: Exactly. It also facilitates shielding the team from distractions as there are no problems turning away any requests that do not fit within the goal.

Motley: What makes an effective iteration goal?

Maven: A user scenario, or set of user scenarios can make effective iteration goals. Pick a couple of end-to-end scenarios that add real user value and deliver one or more features that satisfy those goals. If your team uses user stories (Ed: more on that in a future article), pick a couple from the top of your product backlog and deliver those.

Another common iteration goal is centered around bug fixing, particularly while you are in the integration phase on the glide path to shipping. A good way to specify a iteration goal is to commit the team to fixing a certain number of bugs by the end of the iteration. If we compute the number of hours (after load factor applied) available to the team of developers in the iteration and divide by the average of 5 hours per bug, we can commit to a certain number. Scale accordingly depending on how much time is being spent specifically on bug fixing. For example, if iteration planning tells us we have a team velocity of 400 team hours per iteration, and we spend 5 out of 8 hours in a day on real work we have 250 hours for the team. Given an average of 5 hours per bug, we commit to fixing 50 bugs in the iteration.

Motley: I thought doing a bug fixing "sprint" is not recommended???

Maven: Some teams do them, some don't, as we have discussed in the past. Using the formality of a Scrum sprint is not a necessity, but having a target number of bugs to fix in a certain duration pushes the team, allows you to track progress, and gives you a target to hit. Having a clear goal motivates the team to hit it versus saying "Ok, guys, go fix bugs."

Motley: Fair enough. We will put a goal in place for our next iteration based on our product backlog.

______________________________

Maven's Pointer: You may ask: "What if the backlog items, however, don't align to one particular goal?" I have rarely found that to be the case. My teams have had iteration goals that encompass 2-3 related user stories, and even had iterations focusing on engineering improvements. It typically is not difficult to find commonality. If you are struggling, ask yourself whether you are really building a small enough chunk of functionality that adds user value.

Maven's Resources:

• None this time