Agile Principle #1: Satisfy the Customer


Agile Principle #1 states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.”

Principle #1 is #1 for a reason!  Every team, group or organization has a customer, whether it’s an internal customer, an external customer or both.  The utmost concern for our team must be that we are providing value and satisfying our customer, for without that nothing else really matters.  In almost all cases, satisfying the customer is economically driven and teams have limited people and resources in doing so.  We relatively rank our items to address our most important and valuable items first.  This may be easy and quick for a simple “to do” list or we may have to spend more time for a list of more complex initiatives, always with a watchful eye on expending just enough effort to do so and no more.

Peter Drucker stated “There is nothing so useless as doing efficiently that which should not be done at all”.  Working on the right thing is important and we can increase our success by adhering to best practice relative ranking exercises.  Even in doing so, we can still fall prey to failure. Failure is not necessarily a bad thing.  Much is learned by failure, but if we are going to fail we want to expend the least amount of effort to do so – in other words, “fail fast” to learn.  By failing fast, we can quickly pivot or pick up something new that will provide customer value.

“Through early and continuous delivery” is a phrase in principle #1 that amplifies two significant points which are “leveraging feedback loops” and “maximizing value”.  Feedback is the cornerstone of Agile. Feedback loops are akin to a sailboat tacking to its final destination.  The tighter the feedback loop the better we can adjust and stay on line, but also the more effort we expend on the checking process.  Determine how long you want to sail along before checking your course.  Early and frequent feedback loops with the customer enable us to adapt, pivot and fail fast.

Releasing early and continuously allows us to also maximize value.  If we have 20 things prioritized, we then identify the smallest number of those things that will be of acceptable use to the customer and provide maximum value.  As an example, if we were building the first Automated Teller Machine (ATM) and we wanted the machine to “Withdraw Cash”, “Deposit Funds” and “Inquire on Balance” would it be wise to wait until all three features were available before delivering it to the customer?  Would it be wise to wait for the ATM to be able to remember what your most common withdrawal amounts were and proactively offer those choices?  Or would it be wiser to deliver the ATM as soon as possible without certain features?  These are decisions that you need to make, but the point is that the longer you wait to deliver value to the customer the longer you wait to receive the economic rewards which in turn is losing you money, along with depriving you of essential customer feedback as they use the solution.  So why not deliver the smallest number of features that provides the most economic value and then adhere to Principle #1’s phrase of “through early and continuous delivery of valuable solutions” by then delivering subsequent prioritized features continuously throughout the life of the effort.

Through some of the outlined and other practices we can deliver value to our customers continuously.  Continuously Providing Value = Happy Customer!  🙂

Agile Transformation: It’s an Emotional Thing!

Great People = Great Results!  I read it on the banner of the company I work for everyday as I proceed down the walkway into the building.  People are the most important ingredient in the recipe for your organization’s success and people are emotional beings.

If your company is on its Agile transformation journey, there will inevitably be change and change evokes emotion.  Among the possible emotional catalysts are adopting new processes, taking on new roles, reorganizing, forming new teams and the list goes on.  With this change will come many emotions and related actions.

A frustrated person might constantly get angry and fly off the handle at their colleagues.  Their manager may then tell them, “You really have to suppress your frustration”.  The person then concentrates on suppressing their frustration.  They tell themselves, “Calm down – you’re making too much of this – don’t become frustrated”.

Studies have proven that suppressing thoughts only results in amplifying the thought.  Remember the exercise “whatever you do – do not think of a pink elephant”.  The more you try not to think of the pink elephant, the more you do.  So if we ask someone to suppress their frustration then they will most likely become even more frustrated or even angry.

Instead, Harvard scholars say we need to recognize our emotions, but don’t let them hook us.  We should recognize the emotion as a thought and then zoom up above it, analyze it from this high level and ask ourselves why we feel that way.  By taking the time to identify that our frustration may be signaling an important needed action we can then take that action based on our values and not based on our emotion.

If your boss provides you with negative feedback, this will most likely evoke emotion.  If you get hooked by your emotion then you may jump to the conclusion “My boss has no faith in me”.  Instead, it is better to zoom up above the emotion and ask ourselves which of our values will we use to deal with the trying situation. We can speak to our boss with our values of truth, honesty and transparency to better understand their viewpoint and discuss it.

Again, we should listen to our emotions, but base action on our values.  Our emotions change like the wind, but our values are steady and can be leveraged all the time.

Beginning an Agile Transformation at Your Organization: Shu-Ha-Ri?

I attended the Agile Open Florida event in St. Petersburg Florida and the attendees’ organizations there seemed to be split into three camps:

  1. Some teams within the organization practicing Agile and the other teams practicing Waterfall.
  2. Organization just announced or beginning transformation to Agile (2-6 months into it).
  3. Organization been practicing Agile for a year or more (at different levels of maturity).

My perception was that the majority of the attendees’ organizations fell into Group 2 and I would like to expose them and others interested to the teachings of Shu-Ha-Ri and the question of its adoption.

Shu-Ha-Ri is a Japanese martial art concept where the term translates roughly to “first learn, then detach and finally transcend”.  The definition pulled from Wikipedia follows:

It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”

There are some Agilists that believe organizations should practice Shu-Ha-Ri during their Agile adoption and there are others that feel the practice places a damper on the self-organization and empowerment of the teams.  We could debate it theoretically (the scientist’s perspective), but given the audience I am addressing, I prefer to discuss the actions needed to implement Agile within their world (the engineer’s perspective).

If your organization is just beginning its Agile journey, it would behoove you to select established practice(s) and adhere to their guidelines, whether it be Scrum, Kanban, etc.  Teams should self-organize and be self-governing, but I have seen organizations fail because they do not have the sufficient knowledge to implement the practice.  They make too many changes to the established practice too early or are further handicapped because their organization dictates variations from the start.

The best action is to acquire an experienced coach or consultancy to lead you through your transformation. If you cannot do that then learn the Agile practice(s) you have chosen and try not to deviate unless you feel you have the Agile knowledge and process maturity to do so.  It’s important to follow the practice of Shu-Ha-Ri in inverse proportion to the level of Agile knowledge and experience your organization can draw from. In other words, the less coaching and knowledge available to you the more you should lean on the practice of Shu-Ha-Ri.

It is easy for an organization’s teams to fall prey to deviating from a practice too early.  In most instances, newly assembled teams lack the knowledge and maturity in Agile values (ex: transparency). The theoretical argument might be to let the team change what they want from the very beginning because they will ultimately learn and adapt.  The lessons they learn from the experience will make them a superior team and enable them to become a better empowered and self-governed team.  Theoretically, I would agree with this, but the real world can be harsh.  Your poor decisions have a cost and I do not find the world or many organizations to be overly patient.

So, if you want to succeed on your Agile journey, the best course of action is to have a coach that’s been there before.  If you can’t do that then I wouldn’t stray from the fundamental teachings too much, especially before your Agile acumen is grown. If you are forced with early decisions, then your first step should be to refer to the 12 Agile Principles.  I find more times than not that they set the right direction.


Challenges Ahead During Your Early Agile Transformation Days

As promised, I’ll now address two areas that I believe provide challenges for an organization in its early stage of Agile Transformation; even before an enterprise Agile framework is taken into consideration.  Listed below are two of the most challenging areas, symptoms and possible treatments for some of those symptoms.  Each one of these could become a discussion of their own, but my goal is to give the people in the early stages of Agile Transformation some items to look for and address.  I hope it achieves that purpose for you.

Challenge Area 1 – Mastering Scrum Roles, Artifacts and Activities


  • Product Owner (PO) suggesting or assigning tasks to team members
  • PO anchoring and/or influencing team task estimates
  • PO working on other activities (probably related to previous job position duties) to the detriment of backlog completeness
  • Product backlog items (PBIs) are not ready for planning
  • Backlog Grooming/Refinement is not taking place
  • Scrum Master (SM) driving decisions instead of asking questions to lead the team to their own conclusions
  • Scrum Master allows stand up to have extensive conversations outside of the three questions
  • Team members speak directly to the Scrum Master as they answer their three questions during daily stand ups when they should be speaking to the whole team
  • Team members disengaged at Sprint Planning and Refinement (ex: open laptops, not contributing)
  • Retrospective is a “complain-fest”
  • Team members accepting work from someone other than the PO
  • None of the identified Retrospective improvement Items are actively worked and remediated in subsequent sprints
  • Sprints have too long of a time box eliminating urgency


In many organizations as they start their Agile Transformation the product owner and scrum master roles are filled by project managers and managers.  They sometimes can have minimal experience and education about their new role and fall back on previous command and control practices.  The team may also already be accustom to taking direction from them and everyone easily falls into the old command and control relationship.

If you have a Guiding Agile Partner (strongly recommended) then they should be providing education and direction to individuals and to the group as a whole in a “just in time” (JIT) fashion to correct these situations.  Scrum Masters/Agile Coaches can also provide this direction as they mature in their role.  You can also visibly display Agile definitions, statements, etc. on posters or signs related to your more stingy pain points.

Keeping the product backlog in the proper state is the most important activity for the PO.  The PBIs must be prioritized and in the “ready state” before planning or you greatly risk sprint success (see appendix below for definition of ready).  If the PO is too involved in carrying out work related to their previous role (ex: support or troubleshooting) then it will affect backlog quality.  A cross-training PBI to ramp up a team member and allow the PO to shed their old responsibilities is not out of the question.

It is important that the SM is a servant leader.  They should concentrate on creating a successful process and removing impediments.  They need to ask the right questions and foster participation from all team members.  If team members are only making eye contact with the SM during the daily scrum then this indicates that they feel the daily scrum is a status report for the SM.  The SM needs to remind the team that the daily scrum is not a status report and is meant to share and discover information across the team.  A trick to facilitate the correct mind set here is to let a different team member facilitate the daily scrum each day.  The SM cannot allow team members to enter into long discussions during stand up.  I recommend having a parking lot where you list any items needing longer discussions along with a list of the team members to be involved.  After your daily scrum you can choose to discuss them or schedule a separate time to address.  Your daily scrum should not be more than around 15 minutes.  A cute trick that I learned from a consultancy (AgileThought) and that I use to identify the end of the stand up is to announce “Daily Scrum Dot Done” (DailyScrum.done).  This provides a clear end point so the team clearly knows when they can leave or pick up larger discussions.

Everyone has been involved in a lessons learned, post postmortems or retrospectives.  How many of you have spent time collecting feedback only to never act on remediation?  At the end of your retrospective you can have the team “dot vote” and make sure to include prioritized remediation as part of the next or subsequent sprint.  The Retrospective is a waste of time if you don’t act on the identified items. The SM needs to develop techniques to gain full team participation and uncover important items that need improvement.  There is a lot of information out there on different ways to conduct retrospectives and keep them fresh.

Team members cannot accept work from anyone other than the PO.  Listen carefully as you conduct daily stand ups that no team member is working on a task outside of the sprint and the PO’s knowledge.  Nicely call them out if it is the case.

When it comes to the length of your sprint, I would always recommend that in the beginning you don’t go beyond 2 weeks.  This is purely subjective, but I feel that especially in the beginning of your Agile Transformation it will provide you with a heightened sense of urgency for delivery and provide ample time between retrospectives so you don’t move in the wrong direction too long before correction.  If 2 weeks doesn’t work for you then you can adapt and change it.

Challenge Area 2 – Dependencies Within and Across Teams


  • Unable to start prioritized task within current sprint because limited knowledgeable resource is busy on another task
  • Unfinished Product Backlog Items (PBIs) at end of sprint
  • Time spent waiting on other teams in a current active sprint


In the beginning of your Agile Transformation you have done your best to assign individuals in to cohesive, empowered and self-organizing teams encompassing representation across all of your business areas.  An optimal scrum team has all the needed knowledge and skill sets available within each of their team members so that they may successfully complete their PBIs and provide value to the business every sprint.  This is referred to as being “T-Shaped”.  If all of your team members are “T-Shaped” then you have less likelihood of bottlenecks and wasted time.  If everyone is not “T-Shaped” you can estimate the effort to become “T-Shaped” and construct a plan towards this end while minimally sacrificing the delivery of value to the business.  Obviously, you always need to weigh the time burned to do so vs. the gains produced.

You can accomplish tasks and PBIs more quickly if you do not have to go outside of your individual scrum team.  You aspire to this model, however, it is improbable that you will never have to do so.  Before your Agile Transformation you most likely had some silo groups such as database, middleware integration, etc. You have an issue to address if you don’t have enough people to include at least one of those individuals on each team or if the code is not loosely coupled enabling multiple people to easily work on it simultaneously.  Even though you are not yet ready to adopt an Agile enterprise framework, you may be forced to create a separate team that will field all the other scrum teams’ requests for this skill set area.  I recommend you only do this when absolutely necessary because you can very easily abuse this action and end up right back where you started with silo skillset groups.

In some cases, you require dependencies on other teams.  Since you haven’t scaled yet, you will need to have a Product Owner collaboration session on a regular basis so communications are open and prioritization across teams can initially occur until you adopt an enterprise agile framework (some may say a Scrum of Scrums, SAFe, LeSS, Nexus, Program Team, etc. – but again we are not scaling yet).  My recommendation is to create your PBIs such that they never depend on another team in order to complete the PBI.  If you have a PBI that depends on another team for completion then separate each set of tasks out into their own PBI with the dependency falling in the middle of the two PBIs.  This is not a published practice and other Agilists may have theoretical objections, but it works for me, resulting in less unfinished PBIs and a cleaner more transparent demarcation of dependencies.

In conclusion, I hope this discussion will alert you towards earlier recognition and remediation of some of the more common challenges during the early period of your Agile Transformation.

“Discussion Dot Done” (Discussion.done)!  🙂

Appendix:  PBI “definition of ready” from the book Essential Scrum by Ken Rubin.

PBI Definition of Ready

Agile Transformation: First Step

Let’s face it – there is no specific step by step map to follow for your organization’s agile transformation. Every organization is a unique and complex configuration of people, culture and practices.  As IT professionals we seek an orderly set of specific rules to follow, but I’m telling you based on my experience there is no exact plan that you can follow.  The Rational Unified Process (RUP) which I consider to be one of the first popular iterative methodologies in the late 1990s had difficulty getting initial traction because a majority of early adopters took the published process and tried to implement every single step it described.  Only those who recognized that the process needed to be configured and that they needed to pick and choose the actions for their specific organization and initiatives were able to have success.

So in order to successfully transform our organization we must first start the loop of receiving/eliciting FEEDBACK and ADAPTATION.  As in a sports game, there are many factors that are going to be constantly changing.  You receive feedback, assess the situation and adapt to win.

So where there may not be a step by step guide on how you can transform your organization, the good news is we can provide guidance from our experienced situations, challenges and successful adaptations.  My hope here is that I can share some of my experiences and provide you with somewhere to begin to assemble or supplement your Agile Organizational Transformation.  Please take them as they are, tweak them, add to them, pivot and hopefully share your successful implementations and/or adaptations.

Grass Roots Transformation:  “Influence your leaders to speak to other leaders who have adopted Agile at their organizations.”

My personal experience has taught me that it is difficult to implement an organizational Agile transformation as a grass roots IT initiative without the support of senior leadership.  I have been a part of development teams that have implemented Scrum and were successful in product delivery only to have later projects dictated to follow a different methodology because of educational, political or a list of other reasons.  Consulting companies I speak with say that they will not undertake Agile transformations for companies where senior leadership is not driving or at least in support of the transformation.  If developers are pursuing a “grass roots” attempt to adopting Agile they should introduce their senior leadership to other company success stories and senior leaders that their leaders can speak with about Agile.  The good news is that there are more and more companies, CIOs and CEOs that are embracing Agile.  More early adopters of Agile are now making their way into influential positions within their organizations.  My current organization senior leaders spoke to several other company leaders and were impressed enough to move in the Agile direction.  I can remember the era when all the CIOs were influencing each other to implement an enterprise financial system package.  I am now seeing the same buzz around Agile.  Do whatever you can do to fan the flame.

Supportive Leadership Transformation: “Organize your teams and focus on delivering customer value.”

Some experts advise to transform everything at once.  What’s worked in my experience has been to create your agile teams at the product level first.  Leave your program and portfolio personnel operating in the same manner until you’ve got your lower level product team structure and process working efficiently.   Once you’ve got the product level working then it will be time to address the program and portfolio levels.  The strategy in the way you embark on your agile journey will be strongly driven by the experienced individual or entity guiding your organization.

In the beginning, how you assemble your organization on a managerial and reporting level is something your organization will have to decide and will probably be determined or at least influenced by existing cultural and political conditions.  No matter how you initially decide to organize on an HR and managerial level you must form Agile Teams horizontally across your traditional IT organization. Your HR and managerial structure will be responsible for the career progression and performance of their people.  Each Agile Team will be responsible as a team to deliver the agreed upon value to the business.  When creating your Agile Teams do your best to put the correct people together on the team that can get the job done and limit dependencies on other teams as much as possible.

To do this first identify the business groups you need to support and then identify the corresponding product owners and/or executive sponsors that will represent these groups.  Select the proper people across the skill sets to be on the teams necessary to support each business group.  The product owner and/or executive sponsor now become the entity prioritizing the work to be done for this business group.

If you are currently in a traditional IT organization then you probably have requests coming in from all directions.  Business people roll their eyes and blame IT for the long waiting period to address their request.  Perception that you don’t accomplish much abounds.  The truth is that IT has limited people and resources for all the requests and realistically some will never be completed.  The best way to get out of this situation is to have the product owner and/or the business sponsor receive and prioritize the requests.  If the AP Administrator wants a new report then they request prioritization from their own business organization and not IT.  IT should do the work, but the business will prioritize their own work.  This means no longer are IT the “NO people” and I can tell you that this alone will make a big difference in how you are viewed as an IT organization.

As you begin your Agile transformation, your organization should secure a strong Agile Coach.  This person or guiding entity needs to have the ear and work with your highest executive level.  They will need to work with all of leadership and the Agile Teams and provide guidance and education on a “Just In Time” (JIT) basis.  In my mind it is crucial to have the right guidance as you begin your Agile journey.  With their experience, they will recognize your organization’s pain points and challenges to becoming successful and will address these in priority order as you start to adopt the practice of continuous improvement.

So we have now come full circle – FEEDBACK and ADAPTATION.  As you continue your Agile journey you will recognize things that you want to change from your initial structure, process, etc.  My current company has adapted organizational structure improvements three times in the past year.  You don’t need to get things perfect from the beginning.  Again, feedback and adaptation.

Below is a summary bullet list of considerations for guidance:

  • Gain Support and Involvement from Senior Leadership
  • Enlist Agile Coach Expertise Working Directly With Senior Leadership
  • Create Agile Team Structure Within Your IT Organization
    • Pay particular attention to delivering value at the product level first
    • Define structure best you can – you may have to change it again – ADAPT!
  • Concentrate on delivering business value

Remember:  Feedback and Adaptation to continually improve your transformation!

In the next post I would like to examine some of the challenges you may run into during your initial Agile transformation period.

The CAGE Model

The CAGE Model can assist us in understanding where we are lacking in gaining the Voice of the Customer (VOC).  It visually depicts the critical areas where we must attain information so that the features of our product align with customer needs and that we provide innovation in our product.  Most product failures are due to lack of understanding the customers’ priority needs, believing and implementing everything the customer asks for and absence of any innovative or quality features that differentiate your product from the competition.

Below we will show and explain the CAGE Model.


The CAGE Model has three areas.

The first area is represented in yellow on the diagram and refers to what the product team believes the needs of the customer are before they begin to communicate with the customer in gaining their voice.  Unfortunately, there are a good number of teams which stop here and develop a product based on what they feel the customers need.

The second area is represented in blue and refers to the needs that the customer has told us after gaining the VOC using elicitation techniques.  The product team’s initial understanding (yellow) and the customer’s articulated needs (blue) can overlap differently depending on organization, elicitation techniques, product team knowledge, etc.

The third area is represented in green on the diagram and refers to the “sweet spot” of needs that will make this a great product.  It is comprised of the features that will provide the customer with the needed value and innovation to make the product a “win” in the marketplace.

CAGE Model 2

Outside of the green “sweet spot” lie three areas which identify incorrect requirements.

Area D are the needs that the product team got wrong.  This could have happened by any number of reasons such as having poor knowledge, bad assumptions, etc.

Area B is what the customers got wrong.  Let’s face it customers do not always articulate their needs well and are only human, so may have political motives behind requests that will not necessarily increase product value.  They may also be asking for out of scope features.

Area F is what both the project team and the customer got wrong.  This should not be a great deal of features, but it can happen.

CAGE Model 3

Inside the green “sweet spot” are the requirements and features that will produce a winning product.

Area C represents the customer insights that were not initially recognized by the product team.  The product team needs to use elicitation techniques in order to acquire these.  What techniques and how much to spend needs to be weighed by the team and the organization.  Email surveys cost little and on the other end of the spectrum is ethnographic methods of observing the customer which could have a much higher cost.  This is where your elicitation expertise and practices will make the difference.

Area A is pretty easy – everybody found and agrees that these features are needed.  The project team uncovered them and the customers validated the need.  The customers will definitely be looking for these features in the product.  These features are usually classified as “One Dimensional” (see Kano Model post) and will sway the customer in proportion to how well they have been implemented to customer expectation and competitive product comparison.

Area G are the features the project team identified, but were not voiced by the customer.  In most cases these are the “Must Be” requirement classification type (see post on Kano Model).  These requirements are just so obvious that the customer doesn’t even request them.  For instance if a customer was asking you to build a car for them they probably would not tell you “Now remember, I need a steering wheel” – it just goes without saying.

Area E is the innovative requirements.  These are the “WOW” factor that make your product unique and are a differentiator.  These are the toughest features to uncover, but will make your customer extremely satisfied.

CAGE Model 4

Depending on your team, customers, experimentation and elicitation techniques, to mention a few, you can end up with different CAGE Model overlays.  Practice good elicitation/feedback techniques and maximize your “sweet spot” while minimizing the bad requirements B, D and F areas to gain the Voice of the Customer and create a winning product for your organization!

Kano Model – Not All Features Affect Customer Satisfaction Equally

I delivered a presentation to the Tampa Bay Agile Meetup Group regarding the Voice of the Customer along with two models and two elicitation techniques.  The model and elicitation technique that seemed to spark the most interest was the Kano Model and Kano Survey.


The Kano Model was developed by Dr. Kano in Japan in 1984.  Kano’s assertion was that not all features affected the customer’s satisfaction equally and that customer loyalty correlates to the customer’s emotional response to the features.  Whether a customer buys your product, or not, depends on their emotional response to it.  Different features invoke different responses and it is all based on the perception of the customer.  Value attracts customers, quality builds loyalty and innovation is necessary to differentiate your product and compete in the marketplace.

The model depicts “level of execution” on the X-axis (poor – well) and depicts the “customer satisfaction level” on the Y-axis (very dissatisfied – very satisfied). There are 3 main classifications and 2 additional for a total of 5 in the model.  I will first review the 3 main classifications of “Must Be”, “One Dimensional” and “Attractive” (these are the original labels that Kano assigned, but people have substituted others).

Kano Model

Must Be:  The first classification is “Must Be” (also referred to as the “Must Have”, “Basic”, “Essential”).  This is the type of feature that if not present will make the customer very dissatisfied, but at the same time the fact that the feature is there does not overly satisfy the customer.  An example, might be “soap” in a hotel room.  If a customer does not have any soap in their hotel room they will be very displeased.  These product features are usually so obvious that if you are interviewing a customer they may not even mention them.  The more or better the feature the less displeased the customer will be, but there will be a point where improving on the feature will not make the customer any more satisfied.  In our “soap” example, it would be dissatisfying for a customer if they ran out of soap. So, if you had one or two extra bars of soap then this would keep the customer from becoming dissatisfied,  but having 50 bars of soap in the room would not push their satisfaction level any higher than if you had those couple of extra soap bars.  “Must Be” features do not result in product differentiation and are expected by the customer.

One-Dimensional:  The second classification is “One-Dimensional” (also referred to as “Performance”).  This feature is measured by the customer and the better the measurement is received by the customer then the better the satisfaction and fulfillment level of the feature.  This type of feature is on the mind of the customer when purchasing and if you are ahead of your competitors then you will gain customers.  This feature is usually the easiest to attain/elicit and the customer will most always pay more if you are better than your competitors in this area.  An example of these types of features would be the battery life, disk space and processing power of a laptop computer.  Exceeding your competitors for these features will proportionally grow customer satisfaction.

Attractive:  The third classification is “Attractive” (also referred to as “Exciter”, “Delighter”, “Innovative”, “WOW!”).  These features are unexpected by the customer and contribute to the uniqueness of your product.  These features are innovative and contribute to very high customer satisfaction levels.  They “WOW!” the customer.  These features are difficult to attain/elicit, but have great impact.  Attractive features may diminish over time and eventually even become “Must Be”.  An Attractive feature for my son when he got his new mobile phone was “swipe texting”.  At one time flat screens on a TV were Attractive features, but they are long since expected (“Must Be”) now.

Kano Model - Over Time

The two additional classifications are “Indifferent” and “Reverse”.

Kano Model - Indifferent

Indifferent:  The classification of “Indifferent” relates to features which do not sway the customer’s satisfaction much in either direction whether the feature was executed poorly or well.

Reverse:  The classification of “Reverse” relates to features that dissatisfy the customer if they are present.  An example may be an annoying pop-up message.

In summary, utilize the Kano model to classify your features customer satisfaction levels and deliver a product that meets the basic “Must Be”, maximizes the “One-Dimensional” and includes as many “Attractive” features as possible at a cost the market will bear.  Also, take a look at the Kano Survey below which will explain how to conduct the survey and assess your feature’s customer satisfaction types.


The Kano Survey goes hand and hand with the Kano Model and is the technique used to ascertain the customer satisfaction classification of a feature.  The survey is fairly simple and consists of pairs of questions that are asked to the customer.

Kano Survey

For each feature we ask a pair of questions.  One is positive and one is negative.

Positive:  If you could … how would you feel?
Negative:  If you could not … how would you feel?

The customer answers each question with one of five answers.  They “1-Like”, “2-Expect”, “are 3-Neutral”, “can 4-Live With” or “5-Dislike” it.  For each pair of questions, we take the value of their answers and match them on the survey matrix.  If the customer answered “1-Like” to the feature’s positive question and they answered “5-Dislike” to the feature’s negative question then we would follow the positive column of “1-Like” down until it met the negative column of “5-Dislike” and find that the color at this intersection is blue.  According to the key, blue represents a “One-Dimensional” customer satisfaction type (see Kano Model post for what this means).

If you were a producer of toothpaste a feature of your product might be “easily dispense your toothpaste”.  To attain the customer satisfaction type we would survey customers and aggregate the findings for the following pair of questions.

Positive:  If you could “easily dispense your toothpaste” how would you feel?
Negative:  If you could not “easily dispense your toothpaste” how would you feel?

In conducting the survey your number of responses need to be at a certain level for the survey to meet your needs.  For those mathematically inclined the calculation to determine the minimum survey responses needed is listed below.

Sample Size = (Z-score)² – StdDev*(1-StdDev) / (margin of error)²
Adjusted Sample Size = (SS) / (1 + ((SS – 1) / population))

Population = total number of people represented in your selected universe
Margin of error = willingness for error (ex: +- 5%)
StdDev = standard deviation; how much variance do you expect in responses; (if no preference then use .5)
Z-score – corresponds to confidence level (90%=1.645, 95%=1.96, 99%=2.326)

Example Sample Size:
SS=((1.96)² x .5(.5)) / (.05)²
SS=(3.8416 x .25) / .0025
SS=.9604 / .0025
So, 385 respondents are needed

If you know your population you can then adjust accordingly:
SSadjusted = (SS) / [1 + ((SS – 1) / population)]

Have fun utilizing this technique to gain the Voice of the Customer!

Consider Innovation During Capacity Planning

Innovation Turtle

What I’ve learned is that “Innovation happens when and where it happens”.  You can’t schedule innovation and you can’t create innovation by committee.  Think about it … when do innovative solutions pop into your head?  A moment of time when your mind is free?   During an impromptu discussion with co-workers?  These are the times that innovation happens and although they are not scheduled we need to have time in our day for it. If people are fully tasked with assigned activities throughout the sprint then innovation dies. Even if an innovative idea surfaces, it is immediately squashed by the all ready full plate of commitments and is not given another thought.  Innovation is responsible for the features that will “WOW” the customer.  If your product doesn’t include any of these then you’re going to have a tough time rising above your competition. Collaboration and being a good corporate citizen requires time also.  If you’re having difficulty establishing sprint capacity and at the same time allocating time for innovation, collaboration, learning and good corporate citizenship then take a look at the formula below.  This example is for a 2 week sprint (each developer does this):

  1. Total the number of hours needed for meetings, other scheduled events (scrum events/ceremonies count here), vacation, career building activities, etc. We will call that “Planned Interruptions”.
  2. Potential Available Time = Total hours in the sprint minus Planned Interruptions.
  3. Determine a “Load Factor” which is the percentage of “Potential Available Time” you will allocate to assigned work (planned tasks within the sprint).  Let’s go with 85% for your first iteration and adjust it as needed for future sprints.
  4. Available Time = Potential Available Time * Load Factor.
  5. Unplanned Interruptions = Potential Available Time – Available Time

So if we had determined 12 hours of Planned Interruptions for this developer for a 10 day (8 hours/day) sprint/iteration with a Load Factor of 85% then we would come up with:

Potential Available Time = 80 -12 = 68 hours
Available Time = 68 * .85 =  57.8 = 58 hours (rounded)
Unplanned Interruptions = 68 – 58 = 10 hours

Load Factor Table Image

This would mean with a Load Factor of 85% this developer has an average of 5.8 hours/day to allocate to assigned sprint tasks. Remember, you determine/adjust the Load Factor as you gain experience with your sprints.  Hopefully, this formula can assist teams just starting out on how to assign initial sprint capacity or use it for the long haul if you like.

Unplanned interruptions is where innovation occurs, because it is dedicated to collaboration and collaboration breeds innovation.  It is allocated for any collaboration work that needs to be done outside of assigned tasks and planned interruptions. So, don’t squash innovation and good corporate citizenship at your organization.  Allow for unplanned interruptions, team empowerment and trust to drive innovation forward.