Would anyone please clarify and compare the following concepts,
all related to building a features list and to feature planning:
- subject area
- business activity
- business step
- feature
- feature set
- development plan
FDD says the following about 'Building a Features List':
A team usually comprising just the Lead Developers from the (Process) Develop an Overall Domain Model is formed to functionally decompose the domain into Subject Areas, the Business Activities within them and the Steps within each Business Activity, thus forming the categorised features list.
So our 'features list' consists of a hierachy of 'subject area' - 'business activity' - 'step'.
Which of these three levels are called 'features'? (business activity or step)
Moving to Plan By Feature, 'feature sets' are defined. Each feature set includes a number of features.
To understand this process, I need to know if a feature is a business activity or a step.
I suppose a feature set can contain a subset of multiple subject areas or multiple business activities?
Does a feature set contain business activities including all steps involved, or can a feature set include only part of the features necessary to complete a business activity?
Are there guidelines to decide whether a feature is a 'subject area', a 'business activity' or a 'step'?
How is the 'development plan' structured?
Is it organized by 'subject area', by 'feature set', by 'business activity',....?
Thanks a lot,
Rudy
I'm going to fix this
This mixed set of terms has irritated me for a long time. I was going to use the site glossary to address it (and still will) but I'm also now going to kickoff an activity to try and draw some of the players back to a consensus set of terms. That all said...
From the Lending project the features list hierarchy was
Subject Area->Major->Minor->Feature
Minor was dropped from all reporting as it served no purpose and I've never used this additional level of categorisation since.
From the JMCU book the features list hierarchy was
Major Feature Set->Feature Set->Feature
I strongly dislike this and it's my fault (as author) it ended up that way.
What I use and teach is
Subject Area->Business Activity->Feature
There are two active FDD people that instead use
Subject Area->Feature Set->Feature
That's the history of it.
So,
Subject Area == Major Feature Set
Business Activity == Feature Set
That's the mapping for now. I'm not going to get into a big discussion of the whys and wherefores as I will now (as a priority) get these things renamed and defined with consensus.
The features list is nothing more than simple functional decomposition of the business (of the domain). All we are talking about here is the names for the categories in that list. I believe there is consensus (but I will confirm this) on 3 levels of categorisation in the list. There isn't consensus on what to call the levels.
To answer your other question, the bottom thing in the list - the thing that is collected and categorised is the feature. A Business Activity is a number of features. A Subject Area is a number of Business Activities.
Jeff
My 0.17 euros
I much prefer "Subject Area / Feature Set / Feature". It is a fairly clear hierarchy and quite generic.
Having used FDD on a few non-"business" projects, I prefer to avoid the term and all its implications. As FDD grows and is applied in more projects beyond line-of-business applications, generality will become more important.
:: Gavin -- http://antonym.org/
My 0.17 Euros too.
Much prefer the one provided by Jeff. As I understand the word Business, is an immediate task or objective, and this can be applied to anything. This is more relevant then Feature Set. A synonym of if is Work according to Webster.
But I understand that its meaning is most commonly attached to activity in commerce or the management of money and affairs.
Nuno Lopes
My 0.17 Euros too (reloaded)
As I've said, according to Webster a synonym of Business is work. So probably one an fix this on:
Subject Area -> Work Set -> Feature
or
Subject Area -> Work Activitty -> Feature
or simply
Subject Area -> Work -> Feature
or
Subject Area -> Activity -> Feature
Nuno Lopes
PS: Anyway I think Business Activity is more appealing commercially. So I like it more when describing the method to customers.
Work Package?
Where (or at what level) does Work Package fit into this hierarchy?
Tadd
It Doesn't
This hierarchy describes the features list produced by the Develop Features List process. Once the planning is done and construction has started the workflow is basically this.
Features from the features list are assigned to CP s for design and build. The features that are assigned to CPs can come from anywhere in the features list. That is, I could choose the first feature from the first Business Activity, the fourth feature in the third Business Activity and so on (to contrive an extreme example).
A CP then has an inbox of features assigned to him for design and build. The CP can choose any combination of features from anywhere in the inbox to schedule for design and build right now. He may choose the first feature in his inbox and the seventh (for example). When he chooses these two features for design and build puts them into a thing called a workpackage (note: a workpackage would rarely contain only two features - ths is just an example).
A workpackage is simply a named collection of features that will be put through design and build as a group. When the features are put into the workpackage, the CP sets the plan dates for the feature milestones for all the features in this workpackage.
Here's a basic line drawing of this (it's late and this is all I could do quickly).
On the left is the categorised Features List produced in the startup phase. The subject areas are named using some of your examples from this thread. Under each subject area are indented lines which represent the hierarchy of Business Activities containing Features.
The MY alongside each Business Activity shows the month-year target completion date for that Business Activity (see this newsletter for more on that topic).
Now at runtime in the construction phase, you see in the middle of the diagram a project manager or development manager picking features from anywhere in the features list and assigning them to a CP. On the right of the diagram you can see the inbox of features for that CP and then some have been selected and put into a workpackage below. The workpackage sets the plan dates for the feature milestones and tracks the actual completion dates for those milestones. This is shown by the mini-representation of four features in plan view underneath the CP inbox.
Jeff