Feature Driven Development

"De Luca on FDD Newsletter" Issue 1

Getting Flexible with Planning

Once we have completed the Build Features List process we have a categorized list of features. The top-level category is the Subject Area. These in turn contain Business Activities, that are broken down into features.

When it comes to the Plan By Feature process we are producing, amongst other things, the development plan. Using the categorized features list we plan dates at the level of a Business Activity and only at the granularity of month and year.

As the entire features list has meaning to the client - they are OK with plan dates that to us I.T. folk can seem far too coarse. For example, consider two Business Activities from the domain of Lending (Banking): Credit Evaluation and Loan Approval. If we tell the client they will get Credit Evaluation in February and they will get Loan Approval in March they are fine with that. Those things are relevant and make sense to the client. Remember that all features are expressed in client-valued terms and that the categorization of features into Business Activities is in fact simple functional decomposition of the domain - of their business. These things combined make it easy for the client to accept such dates.

Look at this parking lot chart example from another domain (figure 1). Every Business Activity on it has a planned completion date expressed as a month and year. Clients are fine with such a plan. Every box on that chart means something to them.

However, if we set a plan that says that discrete feature number PM037 - determine the next scheduled Visit for a Patient - will be delivered on Friday the 23^rd at 3pm, then if it isn't delivered at exactly 3pm on Friday the 23^rd we have a "please explain" problem. It is most likely that this single feature being delivered at a time later than published is not a problem at all, but we still have created ourselves a reporting, and potential "please explain," problem.

Project managers can be really good at creating problems for themselves and this is one example of such a self-created problem.

So, we plan and estimate at the level of Business Activity and month and year. Not at the level of individual features linked together (bottom-up) as is often done with a Gantt chart.

Many Project tools make bottom-up task level planning easy to do. We simply open up the tool and start entering tasks. Task 1 is do this thing and that will take about a day. Task 2 is do that thing it it will take half a day. Task 3 will take 2 days, and so on. Then all we have to do is simply swipe select the tasks, click the link button (figure 2) and there we have it: an instant Gantt chart!

There are several problems with this, and here's a discussion of just two of them.

The first is that a Gantt chart is supposed to be resource (people) leveled. It is the utilization of resources and their assignments to tasks that drives the layout of the task bars - in conjunction with finish-start type links between tasks. The simplistic task entry and link approach described previously, completely ignores resource leveling.

The second problem is that there's a massive compound error introduced by trying to estimate each of a very large number of small tasks. The small over-estimates in each task add up to a huge error across the total project.

This is why when we've finished entering all the tasks and their durations and then click the link button we see 4 years for what's supposed to be 15 months worth of work. So, what happens next? Well, we start to drag in those magic Gantt chart bars. You know the ones; they're just like the one below (figure 3). So, we adjust these bars until the overall end date gets close to what our gut thinks or what we know is needed. In this case, somewhere around 15 months.

It's amazing and it's true. I've watched people do this time and again and it is amazing how we can blind ourselves to what is actually happening - which in this case is to undermine our very own Gantt chart work.

A proper Gantt chart is resource leveled rather than simplistically task linked with finish-start links, however very few people use a Gantt chart the proper way. Why? Because it's hard to do and takes a substantial amount of time. Now, imagine resource leveling at the level of granularity of Feature Driven Development features. A granular feature like "generate the unique number for an Order" might be only hours worth of work. When that feature is broken down into the the six discrete milestones required by Feature Driven Development to complete a feature, the task durations are now down to minutes. An extra long toilet visit will break our resource leveled plan.

The operational reality is that a large percentage of Gantt charts are a fantasy of our own making. They're really little more than pretty pictures. But, they're pretty pictures that some rigorous process, or process department, demands. Note: not demands "is useful" but simply demands "is produced."

OK, so we've seen that clients are actually fine with month and year completion dates at the level of a Business Activity in our plan. We've also seen how bottom-up style estimating is flawed and unsuitable for the granularity of features in a Feature Driven Development Project.

There is another big win from keeping the planned completion dates at the level of a Business Activity and at the granularity of month and year when planning and estimating in Plan By Feature Process. That "win" is that we gain a lot of flexibility during the construction phase. This flexibility comes in terms of planning, scheduling, and estimating discrete features or packages of features through the Design By Feature and Build By Feature processes.

As long as we're hitting the completion of whole Business Activities by the month and year set in the plan, we have a lot of flexibility with the features contained by Business Activities. This is touching on a crucial workflow in Feature Driven Development that is the topic of a forthcoming "De Luca on FDD" newsletter.