Issue 4 - Q&A About Feature Milestones

Jeff De Luca's picture

De Luca on FDD Newsletter Issue 4

Q&A About Feature Milestones


Well defined fine-grained milestones is one of the most important innovations in FDD - and the milestones have relevance in terms of business value.

For every feature in the feature list there are six discrete milestones. The milestones are:

  • Domain Walkthrough
  • Design
  • Design Inspection
  • Code
  • Code Inspection
  • Promote to Build

A common question I get is "why is Promote to Build a milestone? After all that's just a click on a button of a version control system." Promote to Build is an important milestone as it gives us a knife-edge sharp definition of finished. That is, a feature is not finished until it is in the build (see newsletter #3 for a discussion of this). Promote to Build is also there as a milestone to capture the latency between the unit testing and code inspection and any changes that may need to be made as a result of them.

Another common question is "why is Domain walkthrough a milestone? After all, didn't we do a whole lot of that during the Develop and Overall Model process?" The Domain Walkthrough for each feature is optional there are two main cases where this per feature walkthrough is needed.

The first case is algorithmic complexity. In the Develop an Overall Model process what we are doing there is shape modeling. That is, identifying all the classes in the domain and how are they connected to one another.

Let's use Lending at a Bank as the domain. During theDevelop an Overall Model process we identify that Loans have terms and conditions applied to them and one of those terms and conditions is the interest rate. Now there's the simple way to calculate interest and then there's the way Banks do it - and with Banks it changes often and for commercial and corporate clients it is negotiated. So, when we are shape modeling during the Develop an Overall Model process we identify a TermAndConditionDescription class that has a method to calculate the interest and that's all we need for shape modeling.

Now, down in the Design By Feature process for a specific feature that calculates interest we need to check back with the domain either in the form of a person or a document or both, to establish what is the algorithm - the formula - for calculating interest.

The second case is data complexity. Again, let's use Lending at a Bank as the domain. When the Loan is a commercial mortgage and it's for a hospital or a hotel, there are a large number of attributes (data elements) that the business wants to capture. For example, the number of rooms, number of beds in a room, which rooms have spas (that would be for the hotel!) and so on.

During the Develop an Overall Model process when we are doing shape modeling, we don't need all those attributes. When we come to Design By Feature for a specific feature that deals with the attributes, then now we do need to know them and again we check back with the domain, either in the form of a document (most likely in thesecases) or a person or both.

Another common question is "why isn't clean compile a milestone?" Having been a programmer myself (long ago) I can empathize with that uplifting moment of a clean compile. However, as a development manager or a project manager, let alone the client, user or project sponsor, a clean compile is meaningless. I can't stand up in front ofthe chairman of the bank and report that the "submit a loan application for approval" feature has clean compiled. It doesn't mean anything.

A feature describes function in the problem domain,while a clean compile is just implementation, and does not mean that the function has actually been delivered (here, again, we see the significance of client-valued features in a features list or a feature breakdown structure).

In newsletter #3 I discuss the problem word finished. Some programmers will give you the finished response at the moment of a clean compile. A clean compile says you have keyed in the syntax of the language correctly (yes, I know this is a simplification) and now you get to prove whether what you've keyed in actually does what it's supposed to. Thus in a technical context, a clean compile doesn't mean much and it certainly doesn't mean finished either.

The other interesting milestones are the design and code inspections and I'll discuss those in the next newsletter.


© Nebulon Pty. Ltd.
With thanks to the review team: Gavin Baker, Phil Bradley, David Bye.