- Log shift activities
- Log in and out times
- Generate XYZ Report
- Export Data to Excel
- View Data in a Range
The above pieces represent the nature of a few types of functionality that are often found on projects. One of the practices I that I follow and recommend to others is of course to determine the business value of each of the features desired. For different businesses the value of each of the above features will be different. The other practice is to seperate the features into engine and bells & whistles after you have determined their business value. So, in the above example Export Data to Excel or View Data in a Range can be a bells & whistles feature if it has very little business value. It is a feature that most likely got added because all the other applications in the industry may have those.
This often gets skipped, but is very helpful for many reasons. Some of them are:
- More experienced people can be handed the responsibility of the engine components.
- Bells & Whistles can always be used as filler features when engine feature(s) planned for an iteration of development are over.
- These are often good pieces that can be used to get new team members upto speed on code. Let's not forget that bells & whistles can be very complicated features to implement sometimes.
There, probably, aren't any rules of thumb by which a feature can be classified as bells & whistle. However, there are certain hints that can be used to figure it out. If the business value is very little compared to some of the other features and/or if the feature being asked for has its inspiration from a lot of commercially available applications, there are high chances that it may qualify as bells & whistles.