Having an “I want it here, I want it all, and I want it now” mindset is one of the quickest ways to derail an Agile Scrum project.
During my experience as a Scrum Coach working in Agile methodologies, I often see a lack of trust between business leaders and IT software development. This leads to a mindset in which the optimal strategy for the business Product Owner is to ask for as many product features as possible, delivered in a highly refined state. The Product Owner might push every opportunity to implement gold-plated, trendy software product features. That mindset, unfortunately, may lead to some ill-fated consequences, like reaching the project end date before the project is completed.
It’s important that Product Owners new to Agile development Scrum realize all product features are not created equal and that they do not each deliver the same value to the end user. An excellent way to think about this is by employing Professor Noriaki Kano’s Dimensions of Satisfaction, which classifies customer preferences into five categories, or “dimensions”:
1. Attractive Quality (satisfying, and unexpected)
2. One-dimensional Quality (satisfying, and expected)
3. Must-be Quality (basic, and expected/taken for granted)
4. Indifferent Quality (have neither a good nor bad effect on the customer’s perception)
5. Reverse Quality (degree of satisfaction depends on the individual customer).
These dimensions determine whether a feature is a “satisfier” (must-have, and expected) or an “exciter” (unexpected).
[Image courtesy of Wikimedia Commons user, Craigwbrown]
Think about the smartphone for a minute. Customers expect a product to have certain basic, must-have features, like a button to initiate a call. Adding two or three different ways to make a call isn’t going to make someone more satisfied. There is no return on investment if you add more than is required of a must-have feature. A feature that adds some excitement, however, like the “Siri” feature on the iPhone, will make people happier with a product.
Adding exciter features can make people happier, but piling them on won’t do as much good as you might think. That’s because most people do not need a product that can do everything, and people aren’t going to miss exciter features if they’re not there. The greatest return on investment is with satisfier features, like a form factor that allows a cell phone to be held in one hand. Every satisfier feature missing will be a negative; every satisfier feature added will improve the approval of a product.
So what does this mean for your agile development project timeline?
Maximizing satisfier features in your Product Backlog
Software development projects employing Agile Scrum use a work list called a Product Backlog to prioritize the expected delivery order of new software features. The Product Backlog is a multi-dimensional representation of the new software. The first dimension is the collection of software functions to be built that allows a user to complete an activity, like register a new user. But, there is another dimension that is critical to the project’s completion in the time available, which is the Dimension of Satisfaction. The Dimension of Satisfaction for a User Story is captured in a Story’s Acceptance Criteria, its features or utility.
The perfect balance
A new software application must possess everything the customer expects as must-have features, just enough satisfier features, and a few delighter features in order to be well received. If I am a rational Product Owner, when considering how I want to spend my time/money over a construction iteration or even over a project, I need to think of this mix of features. This approach maximizes the utility of the features while minimizing the time to deliver.
When helping the Product Owner evaluate acceptance criteria, recognize that a basic, satisfier level of utility is most often going to be the quickest to build and test. Exciter levels of utility are frequently the more difficult features to build and test.
A User Story is an invitation to a conversation. Software developers and testers should help the Product Owner evaluate whether a feature’s Dimension of Satisfaction, Acceptance Criteria is worth the time and effort. The Product Owner and Stakeholders should always think in terms of speed of product delivery: after all, a satisfier feature can always be enhanced and made an exciter feature if you have time. If the Scrum project gets squeezed for time because exciter features are all that are acceptable, you risk project failure.