RX Communica SDLC Journal: Feature Points

Hello there! I’m now writing about SDLC in the form of journal.

The journal will contain my quick insight and ideas taken from best practices, and it also contains my company’s (RX Communica) shared perspective and practices. RX Communica is my own hybrid of non-profit and profit company.

This journal doesn’t have to be in order of learning sequence, not like my F# adventure series. Enjoy!

---

Now I’ll discuss feature point!

Feature point is a weighted score, and it should be based on how much the feature is anticipated based on "MUST HAVE" of Moscow method. It can also have psychological cost, in a sense of the importance of the feature.

At first creation, a feature will have either zero or positive point, but as the feature is used, it can also have negative point.

User feedback, especially when it's focused on a feature will be counted as a weighted score point.

These are the sample use cases and reasonings:

• If there's many negative point for this feature and if this feature is the base foundation for all other feature, then this feature needs to be prioritized to have attention, but it doesn't have to be integrated first. The attention is very critical, that it may lead to feature detach (abandon) or recreate the feature with different logic and refined functional spec and technical requirements. In my previous experience, the integration of this feature can be deferred for next minor or major release, depends on the criticalness.
• The feature that has many negative points should be considered as technical debt that has to be paid soon, as a debt has to be paid in order to decrease critical back log of feature defect that wasn't good thought at the beginning.
• If there's a new feature as the evolution consequence from this feature, then the new feature request based on this one should be rejected or we can investigate further and communicate to the stakeholder that this feature is based on current feature's negative points and it will add more negative points.
  This can lead to further democratization of how we provide the servicing of feedbacks from stakeholder, as if the positive feedbacks don't outweight the negative feedback, we can safely weighing more and leaning more on positive feedback as the source of prioritization consideration. This technique often called "crowdsourcing" but only in scope for software development.
• If the feature has many positive points and also has positive feedback points, then this feature can accept future enhancements.
• The feature (or can be features) that meets our coding and high reliability standard on extensibility (including the notion of Open-Closed principle from SOLID principle) has to be integrated first because it's easier to integrate with high confidence. This feature is therefore have high positive feature points.
• By keeping these green field and feature point concept from start, we will not be trapped easily into brown field model and complexity (smile)

This is to illustrate the fate of a feature in feature points perspective:

If you read the Code Complete 2nd Edition book, the feature point can be used to prioritize integration between features. Feature dependencies should be taken into account first, provided that you have dependency documentation available clearly. If there’s no documentation, then there’s a large possibility that the the software project will fail in the middle of development, test, or even when used in live production.

There’s a video from Channel 9 MSDN website that quickly describe feature point in action. This video is about the introduction to C# 4 design team, but it’s very worthy to watch.

Here’s the link: http://channel9.msdn.com/Blogs/Charles/C-40-Meet-the-Design-Team

NOTE: the feature points not to be confused with feature point matrix of function points.

---

Further references

1. Code Complete 2nd Edition for online reading (if you have Safari account): http://techbus.safaribooksonline.com/book/software-engineering-and-development/0735619670
2. Code Complete 2nd Edition book to buy at Amazon: http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/
3. Function points for measuring algorithm, inputs, outputs complexities: http://www.spr.com/feature-points.html
4. MosCow method: http://en.wikipedia.org/wiki/MoSCoW_Method
5. Crowdsourcing: http://en.wikipedia.org/wiki/Crowdsourcing