I have a question about capturing requirements. I can see the usefulness of the feature naming template, especially as it seems to encourage a fairly fine granularity in the description of the features that can be described. What I do wonder though is how fine grained or even how generic a feature description could/should be. My concern is that we either spend too much time worring about the really nit-picky details early on, or that we end up providing estimates that are too short, or too long because our feature list isn't as fine-grained as it should.
Can anyone think of some examples of feature descriptions that they have considered either too generic, or too finely-grained for use under FDD? Is this something that only personal experience with FDD can teach us?
TIA.
Sean Robins
Not out of context
Hi Sean,
from a feature description alone, someone (outside your team) cannot easily tell if it is too coarse. It is the knowledge from the informational/analytical activity - the Develop an Overall Model process - that enables the team to describe features that are no more than 10 days of work to complete.
Feature Granularity
Hi Sean,
a few comments that may help. But first I wanted to check an assumption.
We do the features list after we've done process one, the initial modelling activity. From your mention of requirements, spending too much time up front and "generic features" just got me wondering if you are using a feature breakdown in the same way. For me it's the knowledge gained from modelling the domain that is the primary input to the "build a feature list" activity, and not directly from the requirements themselves (in whatever form they happen to be). Is that what you are doing, or is it something different?
On granularity itself, the guidelines seem pretty vague at first. At the upper limit we ensure that no feature takes more than 10 days to build. That is, to get through all of the six milestones. If it's bigger than that we decompose it further.
At the lower end we take a different approach to describe the granularity. We talk about trivial methods in our model such as getters and setters, i.e. those methods that do nothing more than providing access to attributes. A feature for a getter or setter level of complexity is too fine grained. We like to aim "just above" that.
So for example a feature like "set the Date of a Sale" is probably too fine grained. Something like "list the Passengers on a Flight" might be closer to the kind of things we'd normally expect to see at the bottom end of the granularity scale. Of course depending on your application that could be a huge task - I'm talking about the trivial case where we have some sort of collection attribute in class A that represents a one-to-many association with some other class B.
One of the key things to consider here is that we want to get a consistency with our feature granularity, as much as is possible. From experience we've found that the particular approach we use ends up with feature being about 3 to 4 days on average. YMMV. This is not a goal - it just falls out that way.
HTH, Paul.