11.19.07
Throw Another Frog on the Liar!
So, to the two of you out there still following this blog (okay, maybe there’s three), I’m sorry to leave you hanging for so long – I know you were all waiting with bated breath. I started a new job in October that has been keeping me quite busy, and I’ve started digging into Erlang (you can see some of my progress in using TDD to learn Erlang on CodeNotes. Lame excuses, I know, but it’s all I’ve got.ﾠ
What’s worse, I am purposely going out of order. I intended from the start for the article on TDD to wrap up this series, so today’s installment will cover “The Planning Game.”
ﾠ
We are just about ready to trip the switch on our nuclear furnace. What we need now is a steady supply of fuel! All this talk of gravity and mass is nice, but there has to be something to burn, otherwise our star’s going to be rather dim. The supply of fuel in a star needs to be metered; relatively constant. When this can no longer be maintained the star begins dying, which results in some spectacular visuals, but isn’t great for the star (see white dwarf, neutron star, or supernova for the gory details).
ﾠ
The parallel to Agile teams is clear: while shoving as much work into every day sounds like a good idea, it almost always ends up in burnout. And like our star, the team may end up putting on a spectacular display for a little while (especially the flying sparks as developers and management clash), but the end result is disaster, both for the project and individual members of the team: product quality suffers, morale suffers and, ultimately, our customer suffers. While this has been the norm in our industry for quite some time, it’s time for things to change.
ﾠ
What if we were able to determine what a given team’s sustainable pace was? What if we could know that, for a given set of team members, there was a constant amount of work they could do over a fixed time period, and do it over and over again… no desperate pushes at the end, no threatened mutinies… no burnout? Maybe this sounds Utopian to some, but I believe it is attainable; it just requires planning and discipline.
ﾠ
The Planning game begins with writing User Stories. These Stories define who the user is, what they want to do, and the value they will derive from doing it. Once we’ve exhausted our customer’s imagination and have written as many stories as we can, we have a Backlog. Each story is assigned a business value by the customer (the current trend is to use the MoSCoW Method) and a Technical Risk (usually something creative like “High”, “Medium” and “Low”) by the technical team members. If we now sort our backlog of stories, first by Business Value (high-to-low) and then by Technical Risk (high-to-low), we have a pretty good idea in which order the stories should be developed. Finally, the technical team members assign “Story Points“, at which point we are ready to begin identifying and working on specific Stories. This is the first form of planning and it happens once, at the beginning of the project (yes, User Stories can always be added to the backlog, but I’m trying to keep this from turning into a tome, so bear with me).
ﾠ
The next step happens at the beginning of every Iteration, and Iterations are fixed-time periods lasting anywhere from one week to one month (two or three week Iterations seem to be the sweet-spot for many teams). For instance, if you start with a three week Iteration, all Iterations should be three weeks in length for the duration of the project. Now the technical team members start pulling stories off the top of the prioritized Backlog until they feel they have enough stories to fill the Iteration. We add up the Story Points for those Stories and that becomes our velocity estimate. At the end of the first Iteration, we perform a demo and the customer either signs off on a story and we (the developers) get full credit for the story, or they do not sign off and we get zero credit. We then can add up the Story Points for all of those “done” stories and we have a velocity for our next Iteration.
ﾠ
From Iteration to Iteration, we check our velocity, making minor adjustments as necessary. After the first couple Iterations, we should see our velocity flatten out – we have now found our team’s optimum pace. Having found it, we can maintain that pace indefinitely. The developers are happy, because they are getting work done and seeing solid, high-quality results (and their families even remember who they are from week to week!). The managers are happy because they can easily take the total number of Story Points of all the stories left in the backlog, divide that number by the team’s velocity, and determine an honest, accurate estimate of when the project will be “done.” Most of all, the customer (or stakeholder) is very happy, because they are seeing the highest business value features actually working at the end of each Iteration (because, of course, they are attending the demo and giving us a “yea” or “nay” on whether or not each Story is done).
ﾠ
Story Points isn’t the only way to track progress on an Agile project, but it is the approach I much prefer, mainly because I think it is the approach that best resists the temptation to revert to old metrics (man-hours being the prime offender). There are more details to the planning game (like determing Acceptance Criteria and a Task List for each Story – I’ll leave it as an exercise for the reader to research these), but hopefully this covered the highlights.
ﾠ
With this approach we have a consistent supply of fuel (User Stories), allowing the team to shine bright and long.
ﾠ
How does “The Planning Game” align with the Agile Manifesto? This one is very easy, because it very solidly aligns with all four core values!
