Limitations of User Stories

Concept

A user story is a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort needed to implement it. It is one of the primary development artefacts for Extreme Programming project teams.

User stories are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer's terminology, without technical or developer oriented syntax.

Argument

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications; the biggest difference is in the level of detail. User stories only provide enough detail to make a reasonable low risk estimate of how long the story will take to implement. When the time comes to implement the story, developers will go to the customer and receive a detailed description of the requirements face to face.

Another limitation of a user story is their dependency to acceptance tests. Indeed, these ensure that it is later possible to determine whether the goals have been fulfilled. Without them, user stories are likely subject to various interpretations, which make them hard to use as a basis for agreement. Thus, they may fail to serve as a form of reliable documentation of the system.

Also, user stories can be difficult to put in place on large projects involving many developers, due to its structure and timely breakdown (Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level). Besides, it relies on developers' competencies, both in interpretation and estimates.

Implementing user stories in a project also requires close and regular customer contact, as they are likely to be updated and modified throughout the project. In some cases, this may be difficult to achieve, not to mention any financial impact on the project's budget and the eventual unnecessary overhead.

Conclusion

Because user stories contain so little information, we need to flesh them out when we first work with them. During the estimation effort, it is common to list programming tasks required to implement the user story. When we start to working on implementation, we may decide to create some rough sketches of what we are going to build, like a screen mock-up or a UML activity diagram representing the relevant business logic. User stories are merely the starting point.