Wednesday, April 6, 2016

Don’t Let the Creep In

No, not the creepy zombie from the Walking Dead.  I’m referring to those extra features that can creep in and increase the scope of your project.  Combating feature creep and scope creep is a constant challenge for software teams. At 10X People we use the term MFR to help avoid scope creep and focus on what is important.

What is MFR/MVP ?
Minimum Feasible Release (MFR) and Minimum Viable Product (MVP) are two terms frequently used on software projects to indicate the minimum set of functionality that can be developed within a defined period of time and within a set budget.  Working within cost and time constraints requires that we focus on the features that deliver the most value to the customer.  As teams design and implement functionality it’s easy to slide down the slippery slope of including “nice to have” features.  Especially when customers are pulling you down that slope.

MFR is one of those concepts that is easy to say, seems straightforward to follow, but it can be difficult to put into practice. Differentiating the important features from the not-so-important  ones can be difficult. When there are strict deadlines or urgency to deliver functioning software, it becomes easier to identify features that can be deferred, and focus on the features that add the most value. The bells and whistles can be added over time if they warrant the cost of implementing them.

Challenging our customers to justify building features is part of our culture. Sometimes this can be misconstrued, and customers may think we are saying that we won’t ever deliver a feature. However, when we challenge the feature set we are merely enabling the focus to be on features that add the most value first.  All of the desired features get put on the backlog and implemented based on priority.

Separating the wheat from the chaff
So, how do we separate the “wheat from the chaff”?  On some teams, an MFR hat displays prominently on the story maps and storyboards. It’s there as a symbol to remind each other to challenge ourselves to justify the value of features. Sometimes we draw a line on our story maps and backlogs and put features that can be deferred below the line as we plan. Additionally, simplicity is a common mantra in our teams.  When things get complicated try to find a way to simplify it and then ask ourselves if the the simple approach is good enough at the point we are in within the project.
Let’s face it, software teams love to build and develop features. But, in the end a successful business relies on the right features being developed at the right time and the right cost.

No comments:

Post a Comment