COEPD – Center of Excellence for Professional Development Happy Learning
If you are working for an agile project, do you write user stories, use cases, or both? Lets discuss each item in detail and then we will differentiate.
User stories are not the same as use cases however they both serve a similar purpose of documenting and an understanding of what the user needs.
WHAT IS A USER STORY
A user story is a simplified description of a requirement or feature written in the form of:As a <who>, I want <what> so that <why>.
A user story expresses one very specific need that a user has. It’s usually written out as a couple of sentences. Most user stories are written in the language of the users, so any user should be able to read a user story and immediately understand what it means.
User Stories are used in agile to help breakdown features into sizable chunks, which can fit into a sprint. The purpose of the User Story is to describe the users or user personas, what they need, and why they need it. The User Story will also have Acceptance Criteria to confirm the user story.
User stories are about needs. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist.
User stories are easy for users to read. When you write a user story, what you’re concentrating on is writing something that anyone can understand, in the language of the users.
WHAT IS A USE CASE
Use cases focus on how your system interacts with other systems and actors and are typically extremely detailed, much more so than a user story.
The purpose of the use case is to describe user or system steps of a process. Use Cases mainly consist of a Title, Description, Users or User Personas, Pre-Conditions, Basic Flow, Alternative Flow, Negative Flows, and Post-Conditions.
A use case is similar to a user story, because it also describes one specific interaction between the user and the software.
Use cases are about the behaviour you’ll build into the software to meet user needs. A developer who needs to build working software should be able to read a use case and get a good sense of what the software needs to do.
Use cases describe a complete interaction between the software and users. It needs to be something that developers can implement. It’s possible that one user story could spawn several use cases.
DIFFERENCES BETWEEN A USER STORY AND A USE CASE
a. A user story is a brief description of functionality as viewed by the user. A use case models the interaction between the actor and the system, a sequence of actions.
b. A user story is short and consist in one or two sentences written in the language of the user. A use case is heavier and too much detailed, richer in information e. g goal, summary, actor, precondition, trigger event, main success scenario and extensions.
c. User stories are used for planning, they play a major role in project estimation and planning. Use cases are not used for planning.
d. User stories emerge faster than use cases. Use cases require more time for analysis and writing.
e. User stories are more readable than use cases. Use cases usually belong to a large document.
f. User stories are easier to maintain than a Use cases Document.
g. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details. Use case is a textual model where everything is documented.
h. A user story must be implemented and tested in one iteration. A specific use case can be implemented in several iterations.
i. User stories can be more easily written by a user or customer. Most of the time use cases are written by business analyst.
j. User stories contain acceptance tests (validation criteria). For use case, tests cases are created in a separate documentation.
USE CASE IN AGILE REQUIREMENTS MANAGEMENT.
User stories define requirements from a user’s perspective and are deliberately written without much detail.
Details are added during conversations with the user and subject matter experts once the user story has been selected for an iteration.
The details during the conversation can then be best documented as use cases. The use cases can then be used to enforce the need for requirements sign off by the stakeholders.
Note that the testing sign off may suffice for acceptance by the business owner, however in some instances it may require some sign off before iteration development commences as part of scope management.
USER STORY: BENEFITS AND CHALLENGES
Benefits
a. Instils customer ownership.
b. Useful for iterative and incremental delivery of solutions.
c. May eliminate the need for more detailed requirements specifications in agile environments where stakeholders and delivery teams are co-located.
d. Clearly defines the value that a features provides.
e. Prioritize with story points for time-boxed iterations.
Challenges
a. Not detailed enough when regulatory restrictions require detailed documentation.
b. May not align with other methods e.g. waterfall methods that are documentation centric.
c. Does not document non-functional requirements well and therefore require additional techniques to be used in conjunction with user stories.
d. Story format may not include enough detail for teams that are distributed.
WHY USER STORY IS THE BEST FIT FOR AGILE
a. Shift focus from writing to talking.
b. Ensures the product is what the user needs and not what they asked for.
c. Stories are comprehensible i.e. Developers and customers understand them, People are better able to remember events if they are organized into stories.
d. Stories are the right size for planning.
e. Stories support and encourage iterative development.
f. Stories support opportunistic development e.g. prioritization.
g. Stories support participatory design.
QUALITIES OF A GOOD USER STORY
Independent
Dependencies between stories lead to prioritization and planning problems.
Dependencies between stories can also make estimation much harder than it needs to be.
Negotiable
User Story are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team.
Valuable to users or customers
The best way to ensure that each story is valuable to the customer or users is to have the customer write the stories
Estimatable
It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code.
Small
Story size does matter because if stories are too large or too small you cannot use them in planning.
The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
Testable
Successfully passing its tests proves that a story has been successfully developed.
Testing enables the developers establish the finished code, whenever possible tests should be automated.
Thank you 🙂
