Skip to content

Category: KanoSyndicate content

It's all about Value, or is it? And if it is all about Value, what is it?

May 22, 2009 by Jack Milunsky

Introduction

In all the scrum literature, there is much rhetoric on focusing on delivering value but there is very little explanation on how you calculate it. Exactly how do you calculate it? I came across an interesting article by Ryan Shriver called "Measurable Value with Agile" where he talks about delivering the right things by choosing tasks based on a cost/benefit analysis, and then delivering those things right with the selected agile method of your choice. Value is then calculated by measuring it via a defined set of identified targets, constraints, and benchmarks. Although I do agree that measuring performance is important, there is still a major problem; if business value can only be measured once a product/feature is delivered, how do you know which user stories to work on first and which ones to avoid? Sure a cost/benefit analysis may be an easy way to determine which tasks to focus on, however, the value of that task is yet to be determined. You can do a cost/benefit analysis, choose the "best" user story based on that analysis, and still deliver a feature that has absolutely zero value. So how do we offset this?

Filling the Product Backlog: Go For Excitement

October 1, 2008 by Peter Stevens


Picture courtesy of jakuza@Flickr

Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.

This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:

  1. Review the format of User Stories and the Kano Model.
  2. For each Role,
    1. Identify the main goals
    2. Identify the functions which that person wants the system to perform to achieve those goals
  3. Decide on next steps: Homework or Implementation

User Stories: Three Steps to Better Presentations

August 27, 2008 by Peter Stevens

Slide 'Waterfall' from Scrum Presentation

As a Scrum Coach, I often take on the role of Evangelist. Monday afternoon, I explained Scrum to the Swiss Java User Group[1]. Although not my first such talk, I had to completely rewrite the presentation. When this was 80% done, the realization hit me: How will I know if the "users" are getting what they need? Why am I not writing user stories?

Agile Software Development on the Xmas edition of the Carnival of Agilists

December 24, 2006 by Artem Marchenko

The series of Kano-model related posts published on this web-site has been noticed and referenced in the Christmas 2006 edition of the Carnival of Agilists - the blogroll about latest thoughts in the agile community.

What a nice Christmas present!

On a side note:
Even though at the moment I am the only one posting to AgileSoftwareDevelopment.com, everybody can register and post his own thoughts here. Every registered user automatically is granted the own blog space and an opportunity to

Kano questionnaire survey analysis

December 8, 2006 by Artem

Different potential user groups and even users within the same group can have different opinions on the product features. The only way to see the high-level picture is to question many users and to gather some statistics on the user preferences. If the user opinions are gathered with the help of Kano questionnaires, the answers can be analyzed in a simple table.

Kano questionnaires

December 5, 2006 by Artem

One of the simplest ways of dividing the product features into must-haves, linear, exciters and even wrong features is to gather the potential customer's opinion with the help of the Kano questionnaires ( PDF ).

Kano model of customer satisfaction

December 2, 2006 by Artem


According to the Standish group research on average 45% of a software features are never used and only 20% of features are used always or often. It means that on average you could develop two times simpler product and sell it for the same price. Potentially gains can be even bigger, for the enterprise scale systems two times simpler product often means four times shorter schedules and ten times simpler integration and testing.

Best of AgileSoftwareDevelopment.com