The product manager did the Kano work properly. Forty customer interviews, the paired functional and dysfunctional questions for every candidate feature, a clean sort into must-be, performance and attractive. The release scope was built from it: every must-be in, the strongest performance features in, two attractive features as the surprise. The team sized that scope against its recent throughput and voted four fingers for 12 March.
Five weeks later the Kano chart on the wiki had not changed. The release had. A large prospect asked for single sign-on, and sales confirmed it was a deal-breaker. A competitor shipped bulk export, and leadership asked for it “as table stakes”. Nobody re-ran the survey. Nobody re-read the date. The roadmap still showed 12 March in green.
What the Kano model is
The Kano model is a feature prioritization framework introduced by Professor Noriaki Kano in 1984. It classifies features by how their presence or absence affects customer satisfaction, rather than by how loudly they are requested. A Kano analysis asks customers two questions per feature: how they would feel if the product had it, and how they would feel if it did not. The pattern of answers places each feature in a category:
- Must-be. Expected. Its absence causes strong dissatisfaction; its presence earns no credit.
- Performance (one-dimensional). More is better. Satisfaction rises roughly in line with how well it is delivered.
- Attractive. Unexpected. Its presence delights; its absence goes unnoticed.
- Indifferent. Customers do not care either way.
- Reverse. Some customers would rather not have it.
A Kano model example most teams recognise: login security is a must-be, page speed is performance, a well-timed shortcut nobody asked for is attractive. A common mapping onto release scope is must-be to Must-have, performance to Should-have, attractive to Could-have.
The Kano classification a product team brings to planning is expert judgment built on customer evidence, and the sizing the engineers put against it is expert engineering judgment. Both are part of the evidence behind the confidence vote, and nothing in this article replaces them.
The categories move. The scope moves with them.
Kano’s own work notes that categories drift over time: what delights today is expected tomorrow. In a product that drift takes years. Inside a release it can happen in a week, and each move lands as scope:
- A must-be surfaces late. A compliance requirement, an enterprise security control, an accessibility obligation. It was not on the survey, and it cannot be negotiated away.
- An attractive feature is promoted. A competitor ships it, and the delighter becomes “table stakes” by decision, not by research.
- A performance target is raised. “Faster” was agreed at the vote; “twice as fast” arrives in a steering meeting.
Each of these is scope creep, the first of the three things that erode a committed release date. It rarely travels alone: a late must-be such as single sign-on often depends on another team’s identity service, which is a dependency, and the people pulled onto it leave capacity gaps elsewhere. The difference with Kano-driven creep is that a must-be cannot be cut. Something already in the release has to move, or the date does.
The Kano chart is rarely re-read against the date. When it is, it answers the question it was built for: which features matter most to satisfaction? It does not answer the one that matters after the vote: what does this reclassification cost the committed date, in days?
Keep the Kano analysis. Price every reclassification.
The answer is not to freeze the categories. Customers and markets move, and a product team that ignores a new must-be ships the wrong release. The answer is to treat the Kano sort as an assumption behind the vote and re-read the date each time it changes.
- At planning, write the committed date and the confidence level the team voted at next to the Kano sort that shaped the scope.
- Rank the release and place the cut-line so the attractive and lower performance items sit below the Must-haves.
- When a feature is reclassified, add its issues to the release and read the re-forecast before anyone agrees to it.
- For a new must-be, name the item of similar size that drops below the cut-line, and read the date again.
- At every sprint boundary, read the gap in days between the committed date and the forecast at the committed confidence.
An illustration, not customer data. A release is committed for 12 March at 85% confidence. At the vote the 85% forecast sits at 9 March: three days of margin. After the vote, single sign-on arrives as six issues and bulk export as four. Scope grows 14%. The 85% forecast moves to 17 March, five days past the commitment. The 50% forecast is 11 March, so the release reads amber, not yet red. Moving the two attractive features below the cut-line brings the 85% forecast back to 13 March.
Now the reclassification has a price on it. Is single sign-on needed for this release, or for the contract signature date? Does bulk export replace a delighter instead of joining it? Is the date renegotiated while there is still margin to trade? Every choice stays with the product owner and the team. What changes is that they make it the week the category moved, with the same number in front of them.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not run Kano surveys or store Kano categories. It reads what a reclassification changes: the issues in the release’s Fix Version. Scope added or removed is tracked in both directions, shown on the burn-up scope line, and expressed as a rate, both a percentage of change and a per-day pace. Those changes flow into the Monte Carlo forecast, so the committed date is re-forecast and the shift is reported in days against the 50%, 85% and 95% bands. The draggable MoSCoW cut-line sits on the same surface, so moving an item below it updates the projected date immediately. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
For the cut-line itself, see taming scope creep with the MoSCoW cut-line. For what to remove when the gap opens, see why descoping is cheapest the week it becomes necessary. For exactly how the cut-line and forecast behave, see the MoSCoW cut-line reference doc.
Key takeaways
- The Kano model sorts features into must-be, performance, attractive, indifferent and reverse by their effect on customer satisfaction.
- The Kano sort and the engineering sizing behind the vote are expert judgment and part of the evidence for the commitment.
- After the vote, categories move: late must-bes, promoted delighters and raised performance targets all land as scope.
- Read the re-forecast before agreeing to a reclassification, and name what drops below the cut-line for every new must-be.
FAQ
What is the Kano model used for?
Kano model prioritization ranks features by how they affect customer satisfaction, separating what customers expect from what improves satisfaction in proportion and what delights them.
What are the five Kano categories?
Must-be, performance (one-dimensional), attractive, indifferent and reverse.
How does the Kano model work in agile release planning?
Using the Kano model in agile planning, teams commit must-bes first, add performance features to fit, and keep attractive features near the cut-line. After the vote, any reclassification should be priced against the committed date before it is accepted.
Sort the features at the vote. Keep the date honest after it. See every reclassification priced against the committed date in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.