Kano Model

The Kano model is a theory of product development and customer satisfaction. It was developed by Japanese researcher Noriaki Kano in the 1980s. The model helps businesses understand and prioritize which features of their product or service will most effectively satisfy and delight customers.

The Kano model categorizes product features into three groups:

  1. Must-have or basic features
  2. Performance features
  3. Delight features

The must-have features are the basic features that customers expect a product or service to have to meet their minimum requirements. If these basic features are not present, customers will be dissatisfied. For example, a smartphone must have a functioning touchscreen and the ability to make phone calls.

Performance features are features that are important to customers and can increase customer satisfaction, but their absence won’t necessarily lead to dissatisfaction. For example, a smartphone that has a long battery life or a high-quality camera.

Delight features are unexpected features that can create a positive emotional response from customers. These features can set a product or service apart from competitors and can create loyal customers. For example, a smartphone that has a built-in projector or has a unique design.

In summary, the Kano model helps businesses to understand what features of their product or service are most important to customers and how to prioritize their development efforts. By focusing on delight features, businesses can create a unique selling point and increase customer loyalty.

Product Owner’s Expertise

Dr. Jason Dworkin, Project Scientist by NASA Goddard Photo and Video is licensed under CC-BY 2.0

A product owner plays a critical role in ensuring that a project meets the needs of the customers and stakeholders. They are responsible for translating the customer’s needs into actionable tasks for the development team. In addition to this, the product owner must also ensure that the project stays within budget and meets the deadline.

While some may wonder whether having expertise in the subject matter of the project is necessary for the product owner, the answer is no. In fact, having someone too close to the subject matter can hinder the project’s progress. This is because they may get too invested in the details and lose sight of the bigger picture. However, it is still important for the product owner to have a basic understanding of the subject matter to communicate effectively with the team members and stakeholders.

On the other hand, a product owner who maintains a high-level view of the project can ensure that it meets the needs of the stakeholders. They also have the necessary communication skills to interact effectively with the team members and stakeholders. This includes the ability to listen actively, ask questions, and provide constructive feedback.

It is essential for the product owner to prioritize requirements effectively, which means they must have a deep understanding of the product vision. They should be able to identify the most critical requirements, allocate resources accordingly, and set achievable goals. In addition to this, the product owner should also be able to identify potential risks and develop contingency plans to mitigate them.

In conclusion, while subject matter expertise can come in handy, having a product owner who is too close to the subject matter can be a hindrance. Instead, a product owner should have strong communication skills, be able to prioritize effectively, and maintain a high-level view of the project. This will ensure that the project meets the needs of the customers and stakeholders and stays within budget and timeline.

Lead Time vs. Cycle Time

Lead Time on Agile Approach

Lead time in Agile approach is the duration between the initiation of a project and the delivery of the final product. In the Agile methodology, the focus is on delivering a high-quality product in the shortest possible time. Therefore, reducing the lead time is a crucial aspect of Agile development.

The lead time can vary depending on the complexity of the project, the size of the team, and the availability of resources. However, in general, Agile teams aim to deliver the product in small increments, with each increment adding value to the final product.

To reduce lead time, Agile teams follow several practices, including continuous integration and delivery, test-driven development, and frequent collaboration with stakeholders. These practices help identify and resolve issues early in the development process, ensuring that the final product meets the customer’s requirements.

In conclusion, lead time is a critical factor in Agile development, and Agile teams strive to reduce it by delivering the product in small increments, following best practices, and collaborating with stakeholders.

Cycle Time on Agile Approach

Cycle time in Agile approach is the duration between the start and completion of a single task or user story. It is the time taken to deliver value to the customer. Agile teams aim to reduce cycle time by breaking down tasks into smaller, more manageable pieces and delivering them incrementally. By doing so, they can identify and address issues early in the development process, ensuring that the final product meets the customer’s requirements.

Product Backlog vs. Work Breakdown Structure

product backlog and scrum
Photo by Startup Stock Photos on Pexels.com

Product Backlog and Work Breakdown Structure (WBS) are two important planning tools used in project management. Although they are similar in some ways, they differ in their scope, purpose, and level of detail.

Product Backlog

A Product Backlog is a prioritized list of features or requirements that a team plans to deliver in a project. It is a dynamic document that is updated continuously throughout the project lifecycle. The Product Backlog is owned by the Product Owner, who is responsible for prioritizing the items based on their value to the customer.

The Product Backlog helps the team to understand and plan what they need to deliver. It is a high-level view of the project that provides a big picture of what the product will look like. The items in the Product Backlog are not broken down into smaller tasks.

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the project deliverables into smaller, manageable components. The WBS breaks down the project into smaller, more manageable pieces that can be estimated and scheduled. Each component of the WBS is called a Work Package.

The WBS is a detailed view of the project and is used to plan and manage the project execution. It is owned by the Project Manager, who is responsible for ensuring that the project is completed on time, within budget, and meets the quality standards. The WBS includes all the tasks required to complete the project and is used to track progress and identify potential issues.


The main differences between Product Backlog and Work Breakdown Structure are:

  • Scope: Product Backlog focuses on the high-level view of the project, while WBS focuses on the detailed view of the project.
  • Purpose: Product Backlog is used to prioritize the features or requirements to be delivered, while WBS is used to plan and manage the project execution.
  • Level of Detail: Product Backlog does not break down the items into smaller tasks, while WBS breaks down the project into smaller, manageable components.

In conclusion, both Product Backlog and Work Breakdown Structure are important planning tools that are used in project management. While they have some similarities, they differ in their scope, purpose, and level of detail. Understanding these differences is crucial for effective project planning and execution.

Scrum for Project Managers E-Book (PDF) 1.0

Are you tired of managing projects that seem to drag on forever? Do you feel like you’re constantly putting out fires instead of making real progress? It’s time to try a new approach.

Introducing Scrum for Project Managers, the e-book that will revolutionize the way you approach project management. Our comprehensive guide will teach you everything you need to know about Scrum, an agile project management framework that has been proven to increase productivity, improve communication, and deliver results.

In this e-book, you’ll learn the basics of Scrum, including how to create and manage a product backlog, how to conduct sprint planning and review meetings, and how to effectively communicate with your team. You’ll also discover advanced techniques for improving team collaboration, managing stakeholder expectations, and delivering high-quality products on time and within budget.

Whether you’re a seasoned project manager or just starting out, Scrum for Project Managers is the must-have resource for anyone looking to improve their project management skills. And with our easy-to-read format and practical advice, you’ll be able to start implementing Scrum in your projects right away.

Chapter 1- Scrum Approach

  • The Agile Manifesto and the Birth of Scrum. 10
  • Overview of Scrum Framework 12
  • Scrum Artifacts 14
  • Organizational Goals in Scrum 16
  • What is the Backlog? 19

Chapter 2 – Product Backlog

  • Product Backlog in Scrum 23
  • An Example of Scrum Practice 25
  • User Stories 27
  • Refining and Estimating Product Backlog 30

Chapter 3 – Sprint Backlog

  • Sprint Backlog 35
  • Sprint Scope and Sprint Goal 37

Chapter 4 – Definition of Done

  • Increment and Definition of Done 42
  • More Details of “Definition of Done” 45
  • When should the DoD be Prepared? 48
  • Definition of Done vs. Acceptance Criteria 50

Chapter 5- Scrum Events

  • What are Scrum Events? 53
  • What is a Time Box? 55
  • More Details About The Sprint 57
  • Sprint Planning Event 59
  • Why is the Sprint Valuable? 61
  • What can be Done in the Sprint? 63
  • How will Things Be Done in the Sprint? 66
  • Who Attends the Sprint Planning Meeting? 68
  • Coherency of Sprint Backlog Items 70
  • Daily Scrum 72
  • Sprint Review Meeting 74
  • Sprint Retrospective Meeting 76
  • Understanding Epics 80
  • Special Sprints 83
  • Canceling a Sprint 85

Chapter 6 – The Scrum Team

  • Scrum Team 88
  • Scrum Team Size 90
  • Product Owner 92
  • What is Value 94
  • How is the Product Backlog Ordered? 96
  • The Developers 98
  • The Scrum Master 100
  • How does the Scrum Master serve to the Scrum Team 102
  • What is an Impediment in Scrum? 104
  • How does the Scrum Master serve to the Product Owner? 106
  • How does the Scrum Master serve to the Organization 108
  • Other Titles in Scrum 110

Chapter 7 – Scaling Scrum

  • Introduction To Scaling Scrum 115
  • What happens when multiple Scrum Teams work on the same Product? 117
  • Impact on velocity when scaling Scrum 118
  • Integrated Product Increments 120
  • The Definition of Done when multiple teams work on the same Product 122
  • Must the Sprints be aligned? (same length, same start/end) 124
  • How many Product Owners are there? 126
  • Feature teams vs Component teams 128
  • The importance of creating an integrated Increment 130

Chapter 8 – Terms and Tools Used in Scrum

  • The Velocity of the Scrum Team 134
  • Technical debt 136
  • Functional and non-functional requirements 138
  • The process of emergence in Scrum 140
  • Burn-down charts 142
  • Burn-up charts 144
  • The “cone of uncertainty” 146

Chapter 9 – Agile Framework and Practices

  • Agile Framework Overview 150
  • Kanban 152
  • Extreme Programming (XP) 155
  • Test-driven development (TDD) 157
  • Behavior-driven development (BDD) 159
  • DevOps 161

Chapter 10 – FAQ about Scrum

  • Is Documentation Mandatory in Scrum? 165
  • What happens with incomplete Sprint Backlog items? 167
  • Who creates the Definition of Done? 168
  • How to change scope without affecting the Sprint Goal? 170
  • What happens if there is no Increment and/or the Sprint Goal is not reached? 171
  • The difference between Product Backlog Refinement and Sprint Planning 173
  • What is the difference between creating an Increment and Releasing it? 175

About The Author

Gökrem Tekir graduated from Anadolu University in 1997 as an Industrial Engineer.

He worked as a project engineer in different companies in the production and service sector. He earned the PMP Certificate in 2004.

After receiving the PMP Certificate, he continued his career as a Project Management Trainer and Consultant.

Among the trainings he gave, there are topics such as Fundamentals of Project Management, Agile Project Management, Scrum Approach, Project Planning and Follow-up with Microsoft Project, PMP Exam Preparation.

The consultancy services offered by Gökrem Tekir are the Establishment and Integration of Project Management Offices, Microsoft Project Server and Sharepoint Integration, Development of Enterprise-Specific Project Management Methods, Planning and Reporting of Projects Between Buyer and Sellers, Creation and Follow-up of Project Plans of Institutions, Projects of Employees. It is listed as Adapting to Management Methods.

Gökrem Tekir is the author of the first Turkish-language Project Management book in 2006. In 2017, a much more comprehensive work titled “Our Life is the Project – Project Manager’s Handbook” was also published.

Gökrem Tekir continues to share information on social networks such as Youtube, Linkedin, Twitter and Instagram in order to spread his knowledge on project management.


  • Download link will be active after payment site.
  • When the new version is published, it will be sent to the email of the buyer.

Buy on ETSY.com

Buy on Kindle