Feature Driven Development: Dev is different than PM

  • Article

I'm seeing the difference more clearly than before: how a team can use Feature Driven Development for development, and how that is different than using FDD for project management.  How could I have missed this?

For Development, FDD means:

  • Take the requirements and convert them to "feature" stories.  (A story is smaller than a use case... often the size of a 3x5 card... that describes the smallest unit of functionality that can be actually demonstrated to the user).
  • Take each feature story and create a "design story" which describes the changes needed for that feature.  Note that a "common" story could be created for two features, or one feature can depend on another... different schools of thought on the same process.
  • Take the design stories and estimate the effort.
  • When performing the work, work on a single design story at a time.  Start the story and finish the story.  Work with others on the team to INSURE that the entire design story can be done in the current iteration (if possible).
  • Report daily on the amount of estimated effort needed to complete the design story (not the time spent... report the time remaining).
  • Demonstrate the feature as soon as possible after completing it

For Project Management, FDD means:

  • Take the feature stories created by the team and organize them into a list.  Number them, group and summarize as needed.  Trace each feature back to the requirements (using the requirement number, assuming one is available).
  • Estimate the amount of time/effort/cost available in the current delivery cycle.  Make sure that the customer is aware of "how much water is in the bucket."
  • Collect the estimates of the effort from the dev team and connect them with the stories.  Assign an "estimated business value" for each story (literally make it up), sort the list by this value, and draw a line at the point where the cost exceeds the available resources in the dev cycle.  This is the initial cutoff that you present to the customer.
  • Get the customer to review the business value for each item.  Sort each time and set the cut-off to show what is "in scope" and what is "out of scope."  Immediate feedback is good.
  • Negotiate any changes in resources and dates depending on the criteria for the project.  (Some projects are date driven, others are cost driven, etc.) 
  • Take the list of items in the accepted list and return to the dev team to plan iterations.
  • If you are using project tools like MS Project or Primevera, add iterations to your project plan (fixing the end date for each iteration), and add tasks directly from the feature/story list.  For each story, put in the total hours estimated for the design story.  (If you break it down further to tasks, make sure that the tasks remain directly tied to the story).
  • Daily collect the hours remaining on each story and insure that your project tracking tool reflects these estimates.  If you are using Scrum, you should be able to predict if your burn-down rate is sufficiently on track to deliver by the end of the iteration.
  • Do not calculate the earned value of any feature until it is complete... then accept 100% of its earned value against the project.

So... why did I detail all of this?  Because I ran across a situation where a team was using FDD for dev, but PM wasn't using FDD for planning or management.  It's a little like being hungry at a buffet table. 

Enough for now.  I hope this makes sense.