Verifiable Business Value
Sometimes when I work on completing stories for an iteration, I get a little sidetracked designing my object model a little too well that I actually impose a lot of work. For example, as I recently tried a TDD exercise using blackjack, I got a little too carried away with designing a Deck object, a shuffler, dealer and player objects, and a table object that players and dealers could fire and recieve events from (i.e. when a player hits, it fires a hit event to the table, which is routed to the dealer, causing the dealer to draw a card for that player if it was their turn). Finally, I even plugged in a rule processor for the table, allowing tables with different rules such as “Dealer does not hit on soft 17″ and “Dealer Must Hit on Soft 17″.
As you can imagine, this took quite awhile to implement before there was a playable demo, an entire rainy Saturday to be exact. A far cry from my goal of completing a TDD exercise in less than 2 hours. Which made me realize something. By keeping things dead simple, perhaps creating a game object with hit, stay, deal, and finish operation, it was doable to create a playable blackjack demo in less than 2 hours, perhaps even less than an hour … it’s not pretty, but there has been Verifiable Business Value delivered.
Which is what is important when working on an iteration … doing the simplest thing that works while providing business value. You provide the verifiable business value first, then refactor to mae the object model more flexible and decoupled. The primary aim is to have something at the end of the iteration that you can show to your end users and even let them play around with while awaitng the next release (or, if you truely are agile, allow them to verify that the business value for this iteration has been met).
Just remember that you can always refactor. 
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
