Thursday, August 27, 2015

Did you remember FDD?

Stuck on stories? (As a user, I want to .... etc ). Maybe you're stuck on who the user is, especially if it's a system actor.

How about features? They're not stories in the SCRUM story sense, but useful nonetheless. How about FDD as a feature driven methodology? Mike Cohn at mountaingoat software has some similar thoughts about FDD.

Recall the feature syntax:
  • Action ... do onto an Object
  • Object .... which by the Action, returns a Result
  • Result ... you did something to an object and this is what you have as a memorial
Oops! This is all strange stuff? Read my whitepaper on

The one thing I've always liked about FDD is its emphasis on a domain model, which for all practical purposes is architecture. This is step one of the FDD process:
  • Do the model -- what objects, what actions, what results?
  • Build a features list (did someone say backlog?)
  • Plan the release (but not by time boxes; there are no time boxes, so more conventional planning is required)
  • Design by feature
  • Develop by feature, where develop includes all the testing steps
Unlike some other Agile methods, FDD practices are built around feature teams that are charged with delivering certain backlog (features: action, object, result). And the teams work to more conventional schedules (no time boxes) but still deliver stuff early and frequently, just like other Agile practices.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog