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.