User Stories (Câu chuyện Người dùng) có thể hiểu là bản tóm tắt về nhu cầu người dùng. Đây là kĩ thuật nhanh và phổ biến nhất để nắm bắt được chức năng sản phẩm. Để làm việc được với User Stories thì dễ, nhưng để kể được câu chuyện hiệu quả của User Stories là rất khó. 10 mẹo sau đây có thể giúp mọi người viết ra được những User Stories hay.

1) Ưu tiên người dùng trước

User Stories miêu tả cách khách hàng hoặc người dùng sử dụng sản phẩm. Mỗi câu chuyện của nó được kể qua quan điểm của họ. Hơn nữa, User Stories đặc biệt hữu ích trong việc nắm bắt một chức năng cụ thể như tìm kiếm sản phẩm hay đặt chỗ cho người dùng. Hình dưới minh họa mối quan hệ giữa người dùng, User Stories và chức năng sản phẩm (được biểu tượng bằng hình tròn).

Nếu chúng ta không biết người dùng và khách hàng là ai và tại sao họ muốn sử dụng sản phẩm thì chúng ta không nên viết bất kỳ User Stories nào cả. Thực hiện những nghiên cứu cần thiết về người dùng trước, như quan sát và phỏng vấn họ. Nếu không, mọi người sẽ có nguy cơ viết ra những câu chuyện đầu cơ dựa trên niềm tin và ý tưởng nhưng không dựa trên dữ liệu và bằng chứng thực nào cả.

2) Sử dụng những đại diện cá nhân để khám phá ra câu chuyện hợp lí

Kỹ năng tuyệt vời để nắm bắt thông tin chi tiết nhất của chúng ta về khách hàng và người dùng là sử dụng đại diện cho các cá nhân. Đây là những nhân vật hư cấu dựa trên kiến thức trực tiếp của nhóm mục tiêu nhất định. Những nhân vật này thường bao gồm tên và hình ảnh; những đặc điểm, hành vi và thái độ có liên quan; và một mục tiêu. Mục tiêu đó là lợi ích mà đại diện cá nhân đó muốn đạt được hay những vấn đề mà cá nhân đó muốn được giải quyết bằng sử dụng sản phẩm

Nhưng hơn nữa, mục tiêu của đại diện cá nhân giúp chúng ta khám phá ra được những câu chuyện hợp lí: Tự hỏi bản thân nên cung cấp chức năng gì để đáp ứng mục tiêu của những đại diện cá nhân. Mọi người có thể tải bản mẫu template để mô tả những đại diện cá nhân tại đây.

3*) Viết những câu chuyện có tính hợp tác

User Stories được thiết kế dưới một dạng kĩ thuật giúp mọi người tiến hành nhanh hơn. User Stories không phải là một đặc điểm, mà là một công cụ hợp tác và không nên đưa cho một đội phát triển developer. Thay vào đấy, User Stories nên được đưa vào một cuộc trò chuyện: người sở hữu sản phẩm và đội phát triển nên thảo luận những câu chuyện đó với nhau. Việc này giúp chúng ta lấy được số liệu thông tin tối thiểu, giảm chi phí và tăng tốc độ vận chuyển.

Chúng ta có thể tiếp cận thêm và viết những câu chuyện có tính hợp tác như là một phần của quá trình sàng lọc trong sản phẩm của chúng ta. Việc này thúc đẩy sáng tạo và kiến thức của nhóm lên và hướng tới những User Stories tốt hơn.

Nếu không thể đưa đội phát triển developer vào User Stories thành công được, chúng ta nên xem xét việc sử dụng kỹ thuật khác để nắm bắt được chức năng sản phẩm như sử dụng Use Case - kỹ thuật được dùng để nắm bắt yêu cầu người dùng từ hệ thống.

4) Giữ cho câu chuyện thật đơn giản và súc tích

Hãy viết những câu chuyện ra thật là dễ hiểu. Giữ cho những câu chuyện đó thật đơn giản và súc tích. Tránh những cụm từ mơ hồ và khó hiểu, và sử dụng giọng nói tích cực. Tập trung vào những gì quan trọng và loại bỏ đi những phần còn lại. Chúng ta có thể hiểu với mẫu ở dưới với tư cách là một đại diện cá nhân để có lợi ích rõ ràng:

"Là <đại diện cho những cá nhân này>,
Tôi muốn <sản phẩm nào đó?>
để tôi <vì sao muốn nó?>."

Sử dụng mẫu như trên mỗi khi thấy có ích, nhưng không phải lúc nào cũng cần phải bắt buộc áp dụng nó. Hãy thử nghiệm nhiều cách khác nhau để viết ra nhiều câu chuyện. Từ đó để biết cái nào phù hợp nhất cho bản thân và cho nhóm.

5) Bắt đầu với câu chuyện thật lớn, sơ sài và thô sơ

Theo thời gian, một câu chuyện lớn, sơ sài và thô sơ sẽ được chia thành nhiều User Stories về sau - tận dụng phản hồi của người dùng trong các bản mẫu ban đầu và số lượng sản phẩm. Chúng ta có thể coi như đây là tiêu đề cho những câu chuyện chi tiết hơn.

Bắt đầu với câu chuyện lớn cho phép mọi người phác thảo ra các chức năng sản phẩm mà không cần đưa ra các chi tiết. Việc này này đặc biệt hữu ích trong việc mô tả các sản phẩm và tính năng mới. Nó cho phép chúng ta nắm bắt được phạm vi thô và giúp chúng ta có thời gian tìm hiểu thêm về cách giải quyết tốt nhất nhu cầu của người dùng.

Việc này cũng làm giảm thời gian và công sức cần thiết để tích hợp thông tin chi tiết mới. Nếu chúng ta có quá nhiều câu chuyện chi tiết trong quá trình tồn đọng sản phẩm, thì thường rất khó khăn và tốn thời gian để liên kết phản hồi tới các sản phẩm thích hợp và dễ nguy cơ dẫn tới những mâu thuẫn.

6) Lọc lại câu chuyện cho tới khi có thể sẵn sàng để kể

Chia câu chuyện lớn, sơ sài, thô sơ thành những câu chuyện nhỏ và chi tiết hơn cho tới khi có thể sẵn sàng để kể. Câu chuyện đó phải là rõ ràng, khả thi và dễ kiểm chứng. Tất cả thành viên trong đội developer nên có hiểu biết chung về ý nghĩa câu chuyện; câu chuyện không nên quá dài và phải phù hợp trong quá trình phát triển; và phải có cách hiệu quả để xác định xem câu chuyện đó đã kết thúc chưa.

7) Thêm tiêu chí chấp nhận

Khi chia câu chuyện lớn thành những câu chuyện nhỏ hơn, hãy nhớ thêm tiêu chí chấp nhận. Việc thêm tiêu chí chấp nhận giúp bổ sung thêm cho câu chuyện. Nó cho chúng ta miêu tả các điều kiện cần phải được đáp ứng để câu chuyện được hoàn thành. Tiêu chí làm phong phú thêm cho câu chuyện. Tiêu chí làm cho câu chuyện có thể kiểm chứng được. Và tiêu chí đảm bảo rằng câu chuyện đó có thể được giới thiệu hoặc phát hành cho người dùng và những bên liên quan khác. Theo quy tắc chung, chúng ta cần sử dụng từ ba đến năm tiêu chí chấp nhận cho các câu chuyện chi tiết đó.

8) Sử dụng thẻ giấy

User Stories xuất hiện trong Extreme Programming (XP) - phương pháp phát triển phần mềm hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng - và các tài liệu XP đầu tiên nói về những thẻ Stories hơn là User Stories. Lý do đơn giản đó là: User Stories được nắm bắt qua những thẻ giấy này. Cách tiếp cận này cung cấp cho chúng ta ba lợi ích. Thứ nhất, thẻ giấy rẻ và dễ sử dụng. Thứ hai, tạo ra điều kiện hợp tác: mọi người đều có thể lấy một thẻ và ghi ra ý tưởng của họ. Thứ ba, những tấm thẻ này có thể tập hợp lại trên bàn hoặc trên tường để kiểm tra sự nhất quán và đầy đủ và giúp hình dung ra được. Dù bây giờ những câu chuyện của chúng ta được lưu trữ bằng điện tử, việc sử dụng thẻ giấy khi viết những câu chuyện mới vẫn đáng dùng hơn.

9) Làm cho câu chuyện có thể đọc được

Câu chuyện là để truyền đạt thông tin. Vậy nên, đừng giấu những câu chuyện đó trên ổ đĩa mạng, trong mạng nội bộ công ty hay trong những phần mềm công cụ khác. Hãy làm cho những câu chuyện này có thể đọc được, như đặt chúng lên tường. Việc này thúc đẩy sự hợp tác, tạo ra sự minh bạch, và làm chúng ta hiểu khi nào chúng ta tạo câu chuyện quá nhiều và quá nhanh, vì khi viết quá nhiều câu chuyện thì sẽ không còn không gian trống để thêm vào nữa. Một công cụ hữu ích cho mọi người tham khảo để khám phá, trực quan hóa và quản lý các câu chuyện đó là Product Canvas.

10) Không chỉ nên dựa quá vào User Stories

Thiết kế Trải nghiệm Người dùng (UX) cần nhiều hơn là User Stories. User Stories hữu ích trong việc nắm bắt chức năng sản phẩm, nhưng User Stories không phù hợp trong việc mô tả hành trình của người dùng và thiết kế trực quan. Do đó, hãy bổ sung User Stories cùng với các kỹ thuật khác, như bản đồ câu chuyện (story maps), sơ đồ công việc (workflow diagram), bảng phân cảnh (storyboards), bản phác thảo (sketch) và mô hình (mockups).

Ngoài ra, User Stories không nắm bắt được yêu cầu kỹ thuật tốt. Nếu cần truyền đạt những yếu tố kiến trúc như component hay dịch vụ nên làm, hãy viết các câu chuyện kỹ thuật (technical stories) hoặc sử dụng ngôn ngữ mô hình hóa như UML.

Cuối cùng, viết User Stories chỉ đáng giá khi chúng ta phát triển phần mềm có khả năng được sử dụng lại. Nhưng nếu chúng ta muốn nhanh chóng tạo ra bản mẫu hay mockup mà sẽ vứt đi để xác định ý tưởng, thì việc viết User Stories là không cần thiết. Hãy nhớ rằng: viết User Stories không phải để dẫn chứng các yêu cầu; User Stories chỉ cho phép chúng ta tiến nhanh hơn và phát triển phần mềm nhanh nhất có thể mà không áp đặt bất kỳ chi phí nào.