
This is a guest post by our friends over at the The Functional BA where they write about all things related to a career as a business analyst.
In today’s post, Stella, who is an IT Business Analyst with over ten years’ experience as a BA, project manager and process improvements, shows us how to write a simple and effective user story that we think you will find useful in your next sprint or software implementation.
With that, take it away, Stella!
A user story is a small, succinct statement of the functionality required to deliver value to a particular stakeholder.
They are used to document the needs of a specific stakeholder and enable teams describe valuable functionalities using short, simple statements.
They can also be used to identify the stakeholders’ needs and prioritize, assess, and plan solutions.
A user story is usually a sentence or two that defines which user’s need is being addressed, the goal the user is trying to fulfill, and any additional information that may be crucial in understanding the range of the story.
They are focused on stakeholder value and encourage further conversations with stakeholders.
User stories are also used to do the following:
- Document stakeholder needs and rank the development of solutions.
- Form the foundation for assessing and planning the solution delivery.
- Form the basis for creating user acceptance tests.
- Act as a criterion for assessing the value delivery.
- Act as an element for tracing related requirements.
- They are an input into project management and reporting.
So how do you write a good user story?
It might seem easy to write a good user story given their simplicity but there are a few guidelines that should be followed when writing a good user story.
- Define the expected result: The user story is considered “done” when the stated task is completed. But in order to complete the task, the expected result has to be clearly defined so that the user knows the expected results.
- Create sub tasks: If numerous steps have to be taken to fulfill the user story, then each of those steps should be created as subtasks in the user story.
- Create user personas: If there are numerous end users in the user story, then you should create multiple stories for each end user instead of merging them all into a single user story.
- A user story per step: a user story should be created for each step in a process, you should not merge all the steps in a process into a single user story.
A user story usually has the following structure
“As a [user persona], I [want to], [so that].”
But what does this mean?
User persona: this is the actor whose wants to accomplish something.
Want to: this is what the actor wants to accomplish.
So that: this is the why the actor wants to accomplish the thigh.
An example of a good user story is:
As a bank employee, I want to create a new customer account, so that the customer can perform their banking transactions.
Every user story should have clear acceptance criteria. Acceptance criterion is a set of conditions that are used to confirm when a user story is completed.
User story example: As a transit supervisor, I want to know the number of available drivers in the pool so that I can plan the bus schedules for the following week.
The acceptance criteria for this user story would be: The application should show the list of available drivers for the following week.
What are Epics: Epics are statements that are used to group a set of related user stories.
But how are Epics and user stories related?
An Epic: A user should be able to create and update their user profiles.
A related user story: As an application end user, I want to be able to create a new user account so that I can access the software application.
A related user story: As an application end user, I want to add profile photos to my user account so that people would be able to identify me.
A user story: As a business analyst, I want to limit the user’s profile picture size so that they don’t upload files bigger than 2 megabyte.
A user story: As an application end user, I want to have a field where I input a brief description of myself so that people can get to know me.
So, Epics are used to provide a summary of our goals and the user stories would break that epic into small, testable, achievable pieces of work.
To create a user story, you should ideally start with an epic and then break the epic into smaller, achievable chunks which become the user stories.
Good user stories should fulfill the INVEST criteria, which is:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
The user stories should be created from the user’s point of view, so if you are in doubt liaise with the user and then use their feedback to help create the user stories.
User stories have their strengths and limitations, which include:
Strengths
- It is easily understood by the stakeholders.
- It can be created through different elicitation techniques.
- It is centered on the stakeholders’ value.
- It allows the stakeholders to have a shared understanding of the need.
- It is ideal for agile projects due to its small, implementable, and testable slices of functionality, which supports quick delivery and regular customer feedback.
Limitations
- The requirements might not be detailed enough for the developers to properly implement.
- The requirements might not be up to the organizational documentation standard or stakeholder expectations. So additional documentation may be required.
Conclusion
In summary, writing an effective user story doesn’t have to require a lot of effort…or time.
By following the steps outlined above, you can quickly write your user stories for your developers so that you can iterate more quickly and remove any of the early stumbling blocks that typically occur when developing software.