Kano and the Agile Project Manager John C Goodpasture Square Peg Consulting  www.sqpegconsulting.com johngoodpasture.blogs...
Kano and Agile are all about user value <ul><li>Kano charts user value from ‘ah-hah!’ to ‘don’t care’ </li></ul><ul><ul><l...
On the Kano Chart, the upper right quadrant is the place to be! Customer Satisfaction Product Functionality - Quadrant Upp...
Everything loses panache over time! Customer Satisfaction Product Functionality + - M  = “must be present” MIB  = More is ...
The sweet spot for agile is the ‘ah-hah!’ quadrant <ul><li>In the ‘ah-hah’ quadrant customers are interested, engaged, and...
Agilists pull out the latent requirements <ul><li>Latent requirements are unknown until revealed by someone else </li></ul...
From Kano comes the business case <ul><li>Scope ah-hah! as the project theme </li></ul><ul><ul><li>Functional, feature-ric...
For more….. <ul><li>Visit  www.sqpegconsulting.com  for free articles </li></ul><ul><li>Search allpm.com & pmi.org for my ...
Upcoming SlideShare
Loading in …5
×

Being Agile with Kano Analysis

2,333 views

Published on

Kano Analysis is a new product requirements tool; Agile is a project method for new products

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,333
On SlideShare
0
From Embeds
0
Number of Embeds
60
Actions
Shares
0
Downloads
74
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Being Agile with Kano Analysis

  1. 1. Kano and the Agile Project Manager John C Goodpasture Square Peg Consulting www.sqpegconsulting.com johngoodpasture.blogspot.com
  2. 2. Kano and Agile are all about user value <ul><li>Kano charts user value from ‘ah-hah!’ to ‘don’t care’ </li></ul><ul><ul><li>‘ Ah-hah!’ is the break-out version of ‘more is better’ </li></ul></ul><ul><ul><li>‘ More is better’ is group-think race to the top </li></ul></ul><ul><ul><li>‘ Indifference’ is yesterday’s ‘ah-hah!’ </li></ul></ul><ul><li>Agile focus’ on projects where user satisfaction is primary </li></ul><ul><ul><li>The product evolves from user experience and adoption </li></ul></ul><ul><ul><li>Change is embraced; indeed, encouraged </li></ul></ul><ul><ul><li>Value is ‘pulled’ into the market, not pushed </li></ul></ul><ul><li>Agile and Kano together bring reality to vision </li></ul><ul><ul><li>Kano analysis kicks off envisioning and exploring </li></ul></ul><ul><ul><li>Kano ‘ah-hah!’s can be the compelling vision for an agile team </li></ul></ul><ul><ul><li>Avoid group-think – it’s not a good place to invest </li></ul></ul>
  3. 3. On the Kano Chart, the upper right quadrant is the place to be! Customer Satisfaction Product Functionality - Quadrant Upper Right Customer Delight Quadrant Upper Left Latent Requirements Quadrant Lower Left Customer dissatisfaction with missing or withheld functions Quadrant Lower Right Customer dissatisfaction with provided functionality Customer Dissatisfaction + - +
  4. 4. Everything loses panache over time! Customer Satisfaction Product Functionality + - M = “must be present” MIB = More is Better Ah = “ah-hah!” In = Indifferent axis MIB decay to M or In Ah decay to In or M Customer Dissatisfaction +
  5. 5. The sweet spot for agile is the ‘ah-hah!’ quadrant <ul><li>In the ‘ah-hah’ quadrant customers are interested, engaged, and energetic </li></ul><ul><li>Early adopters push the ‘ah-hah!’ curve, giving feedback at every iteration </li></ul><ul><li>Ah-hahs! will be copied by competitors </li></ul><ul><ul><li>Eventually the advantage is lost as ah-hah! becomes ‘me too!’ </li></ul></ul><ul><li>Customers may not pay attention to In’s or M’s </li></ul><ul><ul><li>‘ In’ and ‘M’ must be there, even without customer interest </li></ul></ul><ul><ul><li>‘ In’ is the axis for compliance and standards </li></ul></ul><ul><li>The more-is-better horserace leads to group-think </li></ul><ul><ul><li>The race mesmerizes </li></ul></ul><ul><ul><li>MIB’s decay to M’s over time </li></ul></ul><ul><ul><li>Other opportunities may be closed out </li></ul></ul>
  6. 6. Agilists pull out the latent requirements <ul><li>Latent requirements are unknown until revealed by someone else </li></ul><ul><ul><li>I’ll know it when I see it </li></ul></ul><ul><ul><li>Who knew I needed that?! </li></ul></ul><ul><li>Exploratory and envisioning Q&A gets the conversation going </li></ul><ul><ul><li>It’s a conversation, not a quiz </li></ul></ul><ul><ul><li>The value proposition may be very fuzzy </li></ul></ul><ul><ul><li>Prototypes may be needed </li></ul></ul><ul><ul><li>Be aware of non-verbal communication </li></ul></ul><ul><li>Reduce everything to stories that image the vision </li></ul><ul><ul><li>If you can’t draw it, you probably can’t write it! </li></ul></ul><ul><li>Frame all the stories with architecture </li></ul><ul><ul><li>Every product has architecture! </li></ul></ul><ul><ul><li>Make architecture cohesive; keep architecture loosely coupled </li></ul></ul>
  7. 7. From Kano comes the business case <ul><li>Scope ah-hah! as the project theme </li></ul><ul><ul><li>Functional, feature-rich, compelling </li></ul></ul><ul><li>Complete the scope with In, M, and MIB </li></ul><ul><ul><li>Can’t forget these just because they are not exciting </li></ul></ul><ul><li>Estimate the investment </li></ul><ul><ul><li>Dollars per team iteration x Story points* / Velocity** </li></ul></ul><ul><ul><li>*Total backlog **Story points per team iteration </li></ul></ul><ul><ul><li>What does the project benefactor need from the estimate? </li></ul></ul><ul><li>Propose benefits at milestones </li></ul><ul><ul><li>Who’s in the community of beneficiaries? </li></ul></ul><ul><ul><li>What’s their value proposition? </li></ul></ul><ul><ul><li>Show value roll-out at milestones </li></ul></ul><ul><li>Remember: satisfying the customer is more important than following a plan! </li></ul>
  8. 8. For more….. <ul><li>Visit www.sqpegconsulting.com for free articles </li></ul><ul><li>Search allpm.com & pmi.org for my articles </li></ul><ul><li>Read my opinions at johngoodpasture.blogspot.com </li></ul><ul><li>And, look for my new book in January 2010 </li></ul><ul><li>“ Project Management the Agile Way -- Making It Work In the Enterprise” </li></ul>

×