As the product owner, you are well aware that part of the success of your product depends on your decision. Every day, you must be facing:

• How to trade-off with short-term and long-term benefits? How to look for the right decision?
• Who is the stakeholder of your product? What do they need?
• Who is your customer? Did they realize your product value, any gap (Unrealized Value)?
• Did you treat your investors and your partners fair?
• How is your team? Are they motivated and clear about the purpose of the product? What is the level of trust in your team? Are they happy to contribute their effort to the product?
• How do you show yourself as a servant leader to help your team grow and succeed? And why?

Một trong những giá trị thể hiện được một Scrum team có thành công và tiến bộ qua từng Sprint hay không, được thể hiện qua việc Scrum Team xác định được giá trị khách hàng cần, và có cải tiến/tối ưu công việc của mình cần làm trong Sprint để đạt được Sprint Goal hay không. Việc Scrum team xác định/hiểu được nhu cầu của khách hàng, và Development Team tự tối ưu hoá được công việc của mình trong Sprint là điều không dễ dàng, và có rất nhiều hiểu lầm và áp dụng KHÔNG đúng các công cụ và phương pháp như:

• Hiểu sai mong muốn của khách hàng (End User), hay xây dựng chức năng sản phẩm mà khách hàng không cần đến. Do tập trung làm vui lòng nhà đầu tư là người không trực tiếp sử dụng sản phẩm hay chức năng.
• Áp dụng DoD (Definition of Done) một cách máy móc.
• Tập trung quá nhiều vào tốc độ và số lượng, xem đó là KPI phải đạt được, nếu không thì Sprint đó bị xem như thất bại.
• Không có được Sprint Goal rõ ràng.
• Không biết cách tối ưu hóa dòng chảy giá trị.
• Quản lý kiểu cũ, người quản lý đốc thúc và kiểm tra chi lý công việc, ảnh hưởng đến self-organize của team.
• Và nhiều nữa…

Trong khuôn khổ bài này, tôi xin phép tập trung và yếu tố: tối ưu hóa dòng chảy giá trị. Những yếu tố khác đã được tôi chia sẻ qua những bài blog khác trước đây, bạn có thể tìm kiếm để tham khảo thêm.

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".

Vai trò Product Owner đối với Việt Nam còn mới mẻ, chỉ mới vài năm trở lại đây, người ta mới bắt đầu nói về nó, và nhiều công ty bắt đầu cần và tuyển dụng những ứng viên cho vị trí Product Owner. Nhưng thực ra vai trò Product Owner không hề mới, Product Owner là một trong ba vai trò của Scrum, mà Scrum thì đã hơn 20 năm tuổi. 

Definition of Value
​
Human always follows and find Happiness. Although it's very difficult to find, everybody has different happiness. Some people think money is happiness or a happy family, others think happiness is the peace of the soul (like a monk)... So we can say "what makes people happy is value for them".

The company is the same. Of course, every company has an ultimate purpose is revenue (except you are running a non-profit company). So, values of them are making the customer happy, good culture, good processes. over that values is assumed to have more money or save more money.