KK: Avoid Ambiguity in Your User Story

Rated 3.00 out of 5 based on 1 customer rating
(1 customer review)

Rule 4 in How To Write Effective User Stories that Express Business Needs and Minimize Misunderstandings

FREE

Author: Tom and Angela Hathaway
Video Duration: 11:43 minutes

This KnowledgeKnugget™ is part of an eBook and an eCourse

Video Overview

In this KnowledgeKnugget™ you will learn how to apply step 4 to user story writing. This video explains what problems ambiguity in user stories can cause and how to avoid it.

Video Transcript Excerpt

Ambiguous User Stories Need Clarification

In the world of information technology, developers often do not know until their product is finished whether or not it is what the customer wanted. Misunderstood, ambiguous, and assumption-laden statements cause more project failures than any other single factor. Study after study confirms that simple fact. Unless all participants involved in the process of planning, designing, developing, validating and delivering the technology share a common understanding of what they are doing, your projects are at high risk of failure.

The major obstacle to effective communication is ambiguity, meaning using terms and phrases that different members of your target audience will interpret differently. If your project is using an Agile software development approach the project team will address ambiguity conversationally during the elaboration of the user story and we will deal with that in a later KnowledgeKnugget™. However, even in an agile scenario it can be beneficial to remove ambiguity earlier, for example, before you add the user story to the backlog to facilitate Sprint planning. In Waterfall and Iterative development approaches it is much more important to remove ambiguity in the early analysis phases. The less ambiguity you have in the phrasing of a user story at the beginning, the more likely it is that the solution will deliver what you want with minimal cost.

What causes ambiguity in the first place? As the author of the user story, you know what it means. It seems so simple, you would think that the rest of the world should “get it” right away. For instance, assume you are the manager of inventory acquisition in an organization. Your job is to purchase enough of each product to be able to meet future customer demands but not have more than is necessary to avoid tying up too much capital in inventory. When someone asks you what you want your future Automated Product Replenishment (APR) system to do, you might simply say something like, “Well, for starters, we need a forecast”.

… [end of excerpt]

1 review for KK: Avoid Ambiguity in Your User Story

  1. Gretel,

    I agree that it should be further reduced to 2 user stories to increase the simplicity.

    Thanks,
    Tom Hathaway

  2. Rated 3 out of 5

    This was a useful video that really got me thinking about the writer versus the reader and how perceptions of each can be so different. but the resultant user story seemed to contain an exception (non-holiday)which read in our hemisphere in itself could be ambiguous I feel it wasn’t really a simple statement in the end. Could it be simplified further or turned into two user stories to over that exception?

Add a review

Your email address will not be published. Required fields are marked *

You may also like…