Kano Model là một mô hình giúp xác định rõ mối quan hệ giữa việc phát triển sản phẩm và sự hài lòng của khách hàng được xây dựng bởi giáo sư Noriaki Kano vào năm 1980s.

Nhiều bài viết của Scrumviet đã nói về làm sao để tạo ra được sản phẩm đúng với nhu cầu của người dùng. Để trả lời câu hỏi đó không dễ, và đòi hỏi Product Owner phải áp dụng nhiều phương thức, công cụ và kiểm nghiệm liên tục. Nói về công cụ, Kano Model là một trong những công cụ PO có thể sử dụng để xác định mối liên hệ giữa sản phẩm/ chức năng sản phẩm của mình đang đáp ứng được khách hàng của mình thế nào.

Little’s Law là gì?

Little’s Law là một định lý của John Little. Đơn giản là một công thức dùng để thể hiện mối tương quan giữa ba giá trị:

• Work in Progress (WIP): Là số lượng các công việc đã bắt đầu nhưng chưa kết thúc. Lưu ý: sự khác biệt giữa WIP và Limited WIP (Limited WIP là thông số giới hạn nhóm đặt ra để giới hạn số lượng công việc có thể làm cùng lúc). Các nhóm có thể sử dụng WIP để cung cấp sự minh bạch qua đó dựa trên dữ liệu đó nhóm có thể biết được sẽ giới hạn WIP như thế nào và cải thiện dòng chảy của giá trị.
• Cycle Time: Là khoản thời gian khi một mục công việc bắt đầu và khi một mục công việc kết thúc. 
• Throughput: Số lượng công việc được hoàn thành trên một đơn vị/ khoản thời gian. (Ví dụ: Nhóm A hoàn thành 180 points công việc trong vòng 2 tuần.) (Trong một số trường hợp được hiểu là Lead Time).

Để có thể tối ưu hoá được giá trị sản phẩm của mình, các Product Owner phải làm chủ được Product backlog. Nhưng việc quản lý Backlog không hề dễ dàng. Các Product Owner luôn gặp khó khăn trong việc xác định sự ưu tiên của các Product Backlog Items. Sự khó khăn này bắt nguồn từ việc các Product backlog thường chứa đựng rất nhiều thứ khác nhau, đến từ nhu cầu của nhiều bên khác nhau: Khách hàng, CEO, các phòng ban… hay còn là các lỗi hoặc nợ kỹ thuật cần được xem xét.

Sự hỗn tạp này khiến nhiều Product Owner bối rối, và gặp khó khăn khi đưa ra quyết định nên ưu tiên Product Backlog Items nào trước. Hay làm sao kết nối những ưu tiên đó với mục tiêu chung của sản phẩm hoặc doanh nghiệp. Với lý do đó Jeff Patton đã nghĩ ra một phương pháp gọi là User Story Mapping, để giúp Product Owner có thể dễ dàng hơn trong việc sắp xếp thứ tự của các Product Backlog Items (PBIs).

Nói đơn giản: User Story Mapping là một phương pháp sắp xếp phân loại, trực quan hoá Product backlog, giúp cho Product backlog của bạn trở nên dễ quản lý hơn, và thể hiện được sự liên kết giữa người dùng và giá trị mà bạn muốn xây dựng cho họ.

Phương thức này vô cùng đơn giản (Xem hình dưới):

​Wrong determination

People often think that persistence or not giving up will bring them to the success. However looking back to your past, how many times you tried, but did not get a good result? Your determination faced with many failures than successes or even just only failures? Did you ask yourself "Why" and "What is missing to be successful"?

Let's talk about football. Does the football team want to win the cup or want to win all the matches? If you put your expectations on how to win every match, that’s more challenging and might be impossible. But if the goal to win a cup, it will give you a better chance and strategies like you do not need to win all the matches (by accepting the loss or draw in some matches). Or even have a long preparation to be the champion in the couple years rather than this year . 

Having persistence and determination is good but putting it on the right thing, and the right time is more important. The journey to reach the goal is a long journey. And you can have a lot of strategies to achieve it. Knowing how to inspect and adapt the plan or strategy to help you reach the goal; once you failed, you learn from it, change your plan, and continue.

Có nhiều câu hỏi và mối quan tâm về việc quản lý rủi ro xoay quanh việc trao quyền cho Scrum Team như:

Làm thế nào để đảm bảo thành công cho Product nếu Product Owner không hiểu nhiều về Product hoặc chưa đủ kỹ năng? Làm sao Product Owner quyết định được Business Value nào sẽ là trong 20% mang lại 80% giá trị? (80/20 - Pareto Principle)

Việc trao quyền cho Development Team dẫn đến nhiều rủi ro tiềm ẩn? Làm sao Development Team biết nên làm gì và làm thế nào để tạo ra Done Increment?

Nhiều năm trước, tôi bắt đầu tìm hiểu và quan sát cách thức hoạt động của các dự án phần mềm. Lý do tôi quan tâm đến việc này là vì, nhiều dự án thậm chí đã rất thành công trong việc deliver đúng hạn, đạt được đúng yêu cầu đề ra ban đầu, và hoàn thành trong chi phí cho phép. Tuy nhiên, khi nó được đưa ra thị trường thì không ai sử dụng cả. Sau đó sản phẩm đó cũng chết đi để lại nhiều sự lãng phí trong đầu tư và sức lực của các bên để đảm bảo nó được hoàn thành.

Từ đó, trong đầu tôi luôn tồn tại một câu hỏi: Điều gì tạo ra khoảng cách giữa một sản phẩm thành công, được đón nhận bởi người dùng và một sản phẩm thất bại? Qua nhiều năm quan sát, tôi rút ra được một điều, một trong những lý do sản phẩm không được đón nhận như nó được kỳ vọng đa phần là vì nó bị đánh giá sai giữa "Input", "Output" và "Outcome".