This document discusses user stories - a tool used to focus on user needs when starting a project. It defines a user story as a simple statement capturing who wants to complete a task and why. The document provides an example user story and explains that user stories help think from the user's perspective, generate collaboration, and prioritize work without detailed documentation. It recommends writing user stories on cards or a digital board at the start of a project to help plan and guide development.
8. “User stories don’t make you think
about how something will be
implemented;
instead they focus on the who and
the why.”
- Boost New Media http://www.boost.co.nz/blog/2010/09/user-stories/
11. LIBRARY STAFF EXAMPLES
As a library advisor
I want front desk enquiry analysis
In order to improve first level resolution
12.
13. WHY USE THEM
User stories help you …
think from the user perspective
generate discussion and collaboration
communicate requirements:
• in plain English
• without writing detailed documentation
• in bite-size pieces
14. User stories help you …
show value
filter irrelevant content and functionality
drive user research
leave it to the experts to work out the best way of
meeting the user need
prioritise and plan work
WHY USE THEM
18. As a (USER)
The user makes sure you’re thinking about
who will use this feature. If there isn’t an
identifiable user for the feature, reconsider
whether you need it.
COMPONENTS
19. I want to (TASK)
The task or action describes what will
happen, but not how it will happen. User
stories are designed to start a conversation
within the team about the best way to
make this feature.
20. So that (GOAL)
The goal describes the ultimate purpose of
the feature. If you can’t think of one, it’s a
signal that you should reconsider whether
the feature you’re trying to describe is
actually important.
21. LET’S GIVE IT A GO!
As a (ROLE)
I want to (TASK)
So that (GOAL)
Hi! We’re Danielle and Vernon.
We believe the library can better meet users’ goals.
We can achieve this by focusing on the 'who', 'what' and 'why' of library users’ wants and needs.
From analysing user research data, we write user stories to give us this focus.
Before lunch, we’ll cover what a user story is,
why use them,
when and how to,
then it’s hands-on to give it a go!
We have prizes for 3 user stories
User Experience experts from eSolutions will choose winning user stories. Winners will be announced after lunch.
So let’s begin. Dani, what’s a user story?
They’re a simple tool designed to focus on user needs or requirements rather than on product or technology.
User stories are single statements capturing what a user needs to do. A user story captures the 'who', 'what' and 'why' of a requirement in a simple, concise way.
Generally they follow the format: “As a USER I want to TASK so that/in order to GOAL.”
This example has been formulated from a comment in the 2014 Library Client Survey.
However, feedback and comments often have a narrow perspective, pre-maturely fixating on a single solution: “Could you please consider to change all of them [lending laptops]?”
Now for some more examples…
This user story is based on observations from an interview with a postgraduate student, 06 Nov 2015.
Row 104 of the 2014 Library Client Survey comments is where this user story was derived from.
See https://wiki.deakin.edu.au/x/9V22BQ
You could write user stories to clarify your own or your team’s needs.
This user story is from So what do we mean when we say ‘Analytics’? by Mike Jones, January 9, 2014.
http://jisclamp.mimas.ac.uk/2014/01/09/so-what-do-we-mean-when-we-say-analytics/
Added to our own wiki at https://wiki.deakin.edu.au/x/lEe2BQ
This user story is from So what do we mean when we say ‘Analytics’? by Mike Jones, January 9, 2014.
http://jisclamp.mimas.ac.uk/2014/01/09/so-what-do-we-mean-when-we-say-analytics/
Added to our own wiki at https://wiki.deakin.edu.au/x/lEe2BQ
First and foremost, user stories encourage you to think from a user perspective. They take focus away from the product or technology, and even from the SME perspective and put it squarely back on the user.
Good user stories generate discussion and collaboration within your team.
User stories are a great way to communicate requirements.
Because they are written in plain English, everyone should be able to understand the essence of what is required,
While they may not always replace detailed requirement documents, they can be used to break requirements into bite-sized pieces that are easier to digest.
The intention of the user story is to be able to get clarity on each requirement and to be able to respond faster and with less expense.
User stories are precise enough to show value, but allow room to improve and iterate. You can add to, modify or discard them throughout the process.
They can also filter for irrelevant content and functionality. If you can’t write a user story for what you’re thinking about implementing, then it probably shouldn’t exist.
User stories drive user research as we strive to understand the needs we’re gathering. They’re a simple way to incorporate user feedback and comments. … Some of this research is in the persona on your tables.
User stories allow you to leave it to the experts (whoever they may be) to work out the best way of meeting the user need.
And finally, because user stories are bite-sized, they make it easier for us to prioritise and plan work.
User stories are the building blocks to your next project or initiative.
You can create them by writing on cards / whiteboard or in a digital format.
After you’ve written user stories with the Who What and Why, then it’s time to think creatively in solution planning. This might be your team, another team in the Library or it might go to a group outside the library.
Today, we’re not looking at how. Just who, what and why.
So let’s reiterate the components of a user story….
*a note on ‘how’: this bit is left up to the experts to get creative on after the user stories are put together (even if the people creating the user story are the same one’s who’ll create the feature). The point is that at this stage you’re thinking about the who’s and why’s rather than the hows.
To help, you can use:
The persona on your table for the role
The comment from the library client survey
First in groups of 4 or 5, write a user story. (2 minutes)
Choose one user story at your table. (3 minutes) Write your table number in a corner.
Write your names on a separate note. Write your table number in a corner. (1 minute)
Danielle and I will collect your table’s names, user story and send them to our judging panel.
After lunch, judges announce the winning stories.
Choose one user story at your table. (3 minutes) Write your table number in a corner.
Write your names on a separate note. Write your table number in a corner. (1 minute)
Danielle and I will collect your table’s names, user story and send them to our judging panel.