• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Being Agile with Kano Analysis

Being Agile with Kano Analysis



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

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



Total Views
Views on SlideShare
Embed Views



3 Embeds 50

http://www.johngoodpasture.com 42
http://www.slideshare.net 7
http://johngoodpasture.blogspot.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Being Agile with Kano Analysis Being Agile with Kano Analysis Presentation Transcript

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