Có hai loại user story lớn khác nhau:

• Complex user story là những story rất lớn ngay từ đầu và không thể chia tách, nhưng cũng rất hiếm gặp.
• Compound user story là  story mà chứa nhiều user story nhỏ hơn và có thể được phân chia.

Theo nguyên tắc INVEST của một user story tốt (Independent, Negotiable, Valuable, Estimatable, Small, Testable) yêu cầu đối với một user story là nó phải có kích thước nhỏ, hoặc có kích thước phù hợp. Một user story phải đủ nhỏ để có thể được thực hiện trong một iteration. Tất nhiên điều này cũng phụ thuộc vào velocity của development team. Để đạt được mục tiêu này về nguyên tắc, một user story lớn phải được phân chia thành vài user story nhỏ hơn.

Mike Cohn đã tóm tắt năm kỹ thuật mà nhờ đó hầu hết các user story lớn đều có thể được phân chia, đó là SPIDR

Spikes

Spike là một thuật ngữ được sử dụng trong các phương pháp phát triển phần mềm Agile. Spike là những hoạt động, thường là time-boxed activity, của team không nhằm làm ra một sản phẩm (deliverable) mà nhằm thu thập thông tin, hiểu biết để căn cứ vào đó lập ra kế hoạch tiếp theo, hoặc giúp team đưa ra được một ước lượng công việc, hoặc để đánh giá tính khả thi của các công nghệ mới (proof of concept).

Chẳng hạn nếu gặp phải một user story mà team không biết làm thế nào để chia nhỏ vì lẽ không có đủ hiểu biết về giải pháp thực hiện user story đó, thì một architectural spike (cách gọi trong phương pháp XP) có thể là team quyết định dành ra 2h thảo luận xem giải pháp thực hiện user story là như thế nào, và sau architectural spike đó team có thể được hiểu rõ hơn công việc và có thể phân nhỏ được user story.

Paths

Nếu có một số logic path (nhánh rẽ) khác nhau trong một user story, thì một cách chia nhỏ có thể áp dụng là tạo các user story riêng biệt từ một số các path này. Không nhất thiết phải viết một user story cho từng path riêng lẻ, chỉ là nhóm các path theo cách có ý nghĩa. Ví dụ một user story trong đó người dùng có thể trả tiền mua hàng trong một website mua sắm trực tuyến. Hiện tại có hai path có thể: thanh toán bằng thẻ tín dụng hoặc thanh toán bằng Paypal. Về mặt lý thuyết, thanh toán bằng thẻ tín dụng có thể được chia nhỏ hơn, nhưng bạn cần cân nhắc xem liệu mỗi loại thẻ tín dụng có user story riêng có ý nghĩa hay không. Tuy nhiên, nhiệm vụ quan trọng hơn trong việc trả tiền mua hàng được chia thành hai phương án được đề cập. Do đó, những user story mới được tạo ra nhỏ hơn và dễ ước lượng kích thước hơn.

Interfaces

Các giao diện trong bối cảnh này có thể là các thiết bị hoặc loại thiết bị khác nhau, chẳng hạn như điện thoại thông minh được cung cấp bởi iOS hoặc Android. User story của người dùng cũng có thể được phân chia theo sự đa dạng về giao diện. Hãy lấy ví dụ về các hệ điều hành khác nhau. Ví dụ, trong một dự án, có thể có những user story của người dùng liên quan đến việc sử dụng các thiết bị Android và các thiết bị khác như IOS có trình duyệt web khác. Để tránh làm một user story quá lớn vì bao quát toàn diện mọi loại thiết bị người dùng, bạn nên đặt câu hỏi mình muốn phát triển cho loại thiết bị hoặc giao diện nào trước. Có thể iteration đầu tiên sẽ là một user story nhỏ chỉ bao gồm các thiết bị IOS. Một user story khác sẽ bao hàm nhóm thiết bị mục tiêu còn lại.

Data

Một kỹ thuật khác để phân tách các user story của người dùng có thể được sử dụng khi các user story ban đầu chỉ đề cập đến một phạm vi hẹp của dữ liệu có liên quan. Lấy ví dụ về một trang web nhằm thu hút khách du lịch đến một thành phố. Nếu đó là một thành phố nổi tiếng với các bảo tàng, thì  user story đầu tiên có thể bao gồm tìm kiếm thông tin tour về các bảo tàng khác nhau trong khu vực này. Một user story khác tiếp theo có thể bao gồm các tour du lịch khác nhau trong thành phố, và một user story khác bao quát về khả năng tìm kiếm tour theo các hoạt động ngoài trời.

Rules

Business rules hoặc tiêu chuẩn công nghệ có thể là một yếu tố để chia tách user story. Lấy ví dụ về việc mua vé xem phim trực tuyến. Thường có các constraint (ràng buộc) dựa trên yêu cầu kinh doanh của rạp chiếu phim tương ứng, chẳng hạn như giới hạn mua trực tuyến tối đa năm vé cho mỗi địa chỉ email.

Với user story này, có thể chấp nhận rằng development team thoạt đầu sẽ bỏ qua constraint này và cho phép khách mua vé truy cập mua bao nhiêu vé cũng được. Constraint tối đa 5 vé trên một email sau đó có thể được thêm vào trong iteration tiếp theo. Incremental delivery như cách này có nghĩa là những user story lớn ban đầu không được thực hiện toàn bộ ngay lập tức mà thay vào đó nó được chia nhỏ thành những user story thực hiện một số bước nhỏ hơn. Đôi khi việc bỏ qua các business rules ở iteration đầu tiên là có thể được chấp nhận để cho phép bạn nhanh chóng đạt được kết quả thỏa mãn người dùng hoặc khách hàng. Những user story bị bỏ lại ở iteration đầu tiên đó có thể được phát triển trong iteration sau đó.

User story nhỏ – nghĩa là dễ hoàn thành

Việc chia tách user story không phải lúc nào cũng dễ dàng: nhiều agile practitioner mới vào nghề có xu hướng để user story của họ bao quát toàn diện và quá lớn. Nhưng khi bắt tay làm backlog refinement với development team, và cuối cùng là thực hiện các user story, người ta sẽ sớm thấy rằng những user story nhỏ hơn sẽ dễ thực hiện hơn và bàn giao mau chóng hơn. Hãy duy trì việc viết ra các user story đủ nhỏ (Small), có thể ước lượng được (Estimatable) và có giá trị với người dùng (Valuable). Nếu bạn biết cách chia một user story lớn theo một trong số phương pháp SPIDR kể trên bạn hoàn toàn có khả năng làm được. Viết user story cũng theo qui tắc của mọi công việc khác: đó là thực hành nhiều sẽ làm bạn trở nên hoàn thiện.

Theo Katharina Lattenkamp

SPIDR – five simple techniques for a perfectly split user story