Anyone Can Write User Stories. It's the (Shared) Understanding That's ImportantKent McDonald
“Who should write user stories?”
“How can I write better user stories?”
When should we write user stories?”
All questions frequently asked. And all questions entirely missing the point.
Just as the *holding* is the most important part of the rental car reservation, the *shared understanding* is the most important part of the user story.
Join Kent to learn how user stories help you build shared understanding of the right solution with your team. Along the way, learn some techniques to address common issues that stand in the way of getting everyone telling the same story.
Learning Objectives:
* Start with value, then identify stories
* One way to stop solutioning
* Dealing with dependencies (that may not be there) within your backlog
* Ways to split user stories into a more manageable size
* Mapping your way to acceptance criteria
Elicitation and requirements analysis are some business analysis skills that are extremely helpful in an agile setting especially for team members responsible for product ownership. Equally helpful, if not more so, are the skills that teams use to interact with stakeholders, make decisions, and react to actual situations as they arise. The best way to understand the relevance of these skills is to share stories of successful, and perhaps not so successful interactions on real projects and discuss what the team learned. Join Kent as he shares stories from his experiences as Submission System Product Owner and relates the things he learned to useful skills for all business analysts. You’ll get a chance to tell Kent where he went wrong and also consider how to apply the lessons learned in your own setting. Along the way you’ll hear about some techniques for addressing common project situations that work well as long as you get the nuances right.
Analysis In Agile: It's More than Just User StoriesKent McDonald
A common question asked by teams adopting agile is "what does business analysis look like in agile?" The common answer is "writing user stories".
WRONG!
Okay, maybe not wrong, but certainly not the whole story (pardon the pun). Business analysis in agile is concerned with understanding the problem and possible solutions in order to ensure the team is building the right thing. User stories can be helpful, but are certainly not sufficient for doing that.
In this session, Kent McDonald describes how you can perform just enough business analysis to discover the right things to build. This includes how to really use value to decide what to build first, why process flows, data models, and mockups are still extremely helpful, and why the function of user stories is more important than their form.
Along the way, Kent shares examples from a system replacement project he is working on and suggests ways you can apply these techniques to your own projects.
Want to learn, how to make beautiful presentation and impress you colleagues and boost your confidence?..then explore this!!
Many things to learn about powerpoint and proper usage of all the features.
Explore everything inside!!
This is a short powerpoint deck I wrote on how to write powerpoint decks. My staff had a wide range of experience in presenting and the results were often disastrous. This is a simple baseline briefing about guidelines for creating powerpoint presentations. Or not.
Anyone Can Write User Stories. It's the (Shared) Understanding That's ImportantKent McDonald
“Who should write user stories?”
“How can I write better user stories?”
When should we write user stories?”
All questions frequently asked. And all questions entirely missing the point.
Just as the *holding* is the most important part of the rental car reservation, the *shared understanding* is the most important part of the user story.
Join Kent to learn how user stories help you build shared understanding of the right solution with your team. Along the way, learn some techniques to address common issues that stand in the way of getting everyone telling the same story.
Learning Objectives:
* Start with value, then identify stories
* One way to stop solutioning
* Dealing with dependencies (that may not be there) within your backlog
* Ways to split user stories into a more manageable size
* Mapping your way to acceptance criteria
Elicitation and requirements analysis are some business analysis skills that are extremely helpful in an agile setting especially for team members responsible for product ownership. Equally helpful, if not more so, are the skills that teams use to interact with stakeholders, make decisions, and react to actual situations as they arise. The best way to understand the relevance of these skills is to share stories of successful, and perhaps not so successful interactions on real projects and discuss what the team learned. Join Kent as he shares stories from his experiences as Submission System Product Owner and relates the things he learned to useful skills for all business analysts. You’ll get a chance to tell Kent where he went wrong and also consider how to apply the lessons learned in your own setting. Along the way you’ll hear about some techniques for addressing common project situations that work well as long as you get the nuances right.
Analysis In Agile: It's More than Just User StoriesKent McDonald
A common question asked by teams adopting agile is "what does business analysis look like in agile?" The common answer is "writing user stories".
WRONG!
Okay, maybe not wrong, but certainly not the whole story (pardon the pun). Business analysis in agile is concerned with understanding the problem and possible solutions in order to ensure the team is building the right thing. User stories can be helpful, but are certainly not sufficient for doing that.
In this session, Kent McDonald describes how you can perform just enough business analysis to discover the right things to build. This includes how to really use value to decide what to build first, why process flows, data models, and mockups are still extremely helpful, and why the function of user stories is more important than their form.
Along the way, Kent shares examples from a system replacement project he is working on and suggests ways you can apply these techniques to your own projects.
Want to learn, how to make beautiful presentation and impress you colleagues and boost your confidence?..then explore this!!
Many things to learn about powerpoint and proper usage of all the features.
Explore everything inside!!
This is a short powerpoint deck I wrote on how to write powerpoint decks. My staff had a wide range of experience in presenting and the results were often disastrous. This is a simple baseline briefing about guidelines for creating powerpoint presentations. Or not.
Seven Common Webinar Mistakes and How to Avoid ThemWiley
There are many common webinar mistakes that can prevent an otherwise excellent presentation from getting the praise and attention it deserves. Here we share some tips and tricks to help you avoid these pitfalls and pull off a successful webinar.
Informed & Agile: Test Driven Design w/ Jon InnesUserZoom
Do you find yourself sprinting without a clear direction? Pushing feature after feature out, only to wonder if your app or website is really getting better? Join Jon Innes of UX Innovation in a webinar on-demand, where he will discuss how to improve your sprints by incorporating UX/usability metrics that the whole team can use to measure progress on your agile journey as a product team.
Putting personas to work - University of Edinburgh Website ProgrammeNeil Allison
I use personas to support the development of the University of Edinburgh's corporate Content Management System and associated services.
A significant challenge is to try to ensure that all members of the team understand and empathise with the personas that represent our CMS user group.
This session (first presented February 2014 at a Web Publishing Community session) outlines activities I use to help foster shared understanding within the team and wider group of stakeholders.
Disciplined Entrepreneurship: What can you do for your customer?Elaine Chen
In this class, we will explore how, given a target market and chosen user persona, we can come up with a solution that solves these problems and meets the needs and wants of the customer. We will discuss how to come up with ways to develop high level product concepts that can be tested in the field. We will cover hypothesis testing techniques, including classical quantitative techniques like usability benchmarks as well as modern techniques such as the use of landing pages to test product interest and purchase intent.
Learn to do Primary Market Research: Interviews and SurveysElaine Chen
This talk is an interactive workshop with live demonstrations and simulations. Participants will practice their interview skills as well as on-line survey design skills and learn from each other in the workshop. Novices and veterans alike will gain new skills in a group setting.
"How to write better User Stories" por @jrhuertawebcat
Presentación realizada en el #webcat Barcelona de Abril 2013
Autor: José E. Rodríguez (@jrhuerta)
------------------------------------------------
RECURSOS:
- Agile Barcelona
http://agile-barcelona.org/
- "User Stories Applied: For Agile Software Development", Mike Cohn, 2004, Addison-Wesley Professional
http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
- "Lean UX", Jeff Gothelf & Josh Seiden, 2012, O'Reilly Media
http://www.leanuxbook.com/
Through the webinar, she will give an introduction to the user story concept. How to create them? How they can help us build better products for our customers. Do's and Don'ts.
Agile Network India | Effective User story writing and story mapping approachAgileNetwork
Session Title: Effective User story writing and story mapping approach
Abstract:Get a high-level view is story mapping, how to create features and epics, release planning and key concepts to understand how stories work and how they come to life in Agile a story’s lifecycle. Example of effective Agile scrum User story.
Key Takeaways:
1. Learn how to convert this to working software.
2. User story vs Use Case
3. Flat backlog vs story map
4. Technical vs functional stories
5. Creating stories collaboratively.
Seven Common Webinar Mistakes and How to Avoid ThemWiley
There are many common webinar mistakes that can prevent an otherwise excellent presentation from getting the praise and attention it deserves. Here we share some tips and tricks to help you avoid these pitfalls and pull off a successful webinar.
Informed & Agile: Test Driven Design w/ Jon InnesUserZoom
Do you find yourself sprinting without a clear direction? Pushing feature after feature out, only to wonder if your app or website is really getting better? Join Jon Innes of UX Innovation in a webinar on-demand, where he will discuss how to improve your sprints by incorporating UX/usability metrics that the whole team can use to measure progress on your agile journey as a product team.
Putting personas to work - University of Edinburgh Website ProgrammeNeil Allison
I use personas to support the development of the University of Edinburgh's corporate Content Management System and associated services.
A significant challenge is to try to ensure that all members of the team understand and empathise with the personas that represent our CMS user group.
This session (first presented February 2014 at a Web Publishing Community session) outlines activities I use to help foster shared understanding within the team and wider group of stakeholders.
Disciplined Entrepreneurship: What can you do for your customer?Elaine Chen
In this class, we will explore how, given a target market and chosen user persona, we can come up with a solution that solves these problems and meets the needs and wants of the customer. We will discuss how to come up with ways to develop high level product concepts that can be tested in the field. We will cover hypothesis testing techniques, including classical quantitative techniques like usability benchmarks as well as modern techniques such as the use of landing pages to test product interest and purchase intent.
Learn to do Primary Market Research: Interviews and SurveysElaine Chen
This talk is an interactive workshop with live demonstrations and simulations. Participants will practice their interview skills as well as on-line survey design skills and learn from each other in the workshop. Novices and veterans alike will gain new skills in a group setting.
"How to write better User Stories" por @jrhuertawebcat
Presentación realizada en el #webcat Barcelona de Abril 2013
Autor: José E. Rodríguez (@jrhuerta)
------------------------------------------------
RECURSOS:
- Agile Barcelona
http://agile-barcelona.org/
- "User Stories Applied: For Agile Software Development", Mike Cohn, 2004, Addison-Wesley Professional
http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
- "Lean UX", Jeff Gothelf & Josh Seiden, 2012, O'Reilly Media
http://www.leanuxbook.com/
Through the webinar, she will give an introduction to the user story concept. How to create them? How they can help us build better products for our customers. Do's and Don'ts.
Agile Network India | Effective User story writing and story mapping approachAgileNetwork
Session Title: Effective User story writing and story mapping approach
Abstract:Get a high-level view is story mapping, how to create features and epics, release planning and key concepts to understand how stories work and how they come to life in Agile a story’s lifecycle. Example of effective Agile scrum User story.
Key Takeaways:
1. Learn how to convert this to working software.
2. User story vs Use Case
3. Flat backlog vs story map
4. Technical vs functional stories
5. Creating stories collaboratively.
Successful Business Sponsorship of Agile IT ProjectsChris Mundy
The role of the Business Sponsor of a technology project is to ensure it successfully delivers. These slides suggest some areas to ask questions about if you are Business Sponsor of a project being delivered using Agile methodology
Slides talk about importance & guidelines of sketching and story boarding. It discusses two approaches about "getting the design right" or getting the right design". Steps and Do's/Dont's of storyboarding
User Stories Writing - Codemotion 2013Fabio Armani
Stefano Leli (Freelance) - Fabio Armani (OpenWare)
Scrivere user stories dovrebbe essere facile...almeno in teoria. In realtà nella pratica ci troviamo troppo spesso a combattere con storie vaghe o troppo tecniche, storie che non possono essere testate o addirittura che non portano alcun valore. In questo workshop cercheremo assieme di comprendere la differenza tra requisiti funzionali e User Story, tra User Story e Use Case, mediante dei case study.
User stories writing - Codemotion 2013Stefano Leli
Stefano Leli (Freelance) - Fabio Armani (OpenWare)
Scrivere user stories dovrebbe essere facile...almeno in teoria. In realtà nella pratica ci troviamo troppo spesso a combattere con storie vaghe o troppo tecniche, storie che non possono essere testate o addirittura che non portano alcun valore. In questo workshop cercheremo assieme di comprendere la differenza tra requisiti funzionali e User Story, tra User Story e Use Case, mediante dei case study.
Untangling Agile Estimation - PMI Houston 2019 SymposiumJami Anderson
As more organizations transition to Agile, one of the obstacles they have to overcome is proper estimation techniques in the new methodology. This session presented by Panayiotis “Takis” Melas, PMP, CSM, SSM, SPC, Sr. Consultant/Agile Coach for MI-GSO | PCUBED, covered the core concepts of Agile estimation, and discussed recommendations and pitfalls in breaking down the work segments and estimating the work to be performed, unlocking one of the most valuable components of the Agile methodology. @MIGSOPCUBED_off
Life cycle of user story: Outside-in agile product management & testing, or...Ravi Tadwalkar
It has always been my pleasure and fun to facilitate workshops for PM (product management) community at and outside Cisco, although this was first time I did a BDD workshop with PMs alone. And I realized today how PayPal has been a really great venue for SVPMA annual product camp "unconference" for 1k+ PMs with 550 waitlisted this year! I look forward to this event every year now...huge success!
Abstract:
As Product Owners and Managers are driving innovation thru' those fuzzy ideas in terms of scenarios, testers have always been thinking about those in form of test cases which take form of acceptance criteria for those scenarios. When you talk about those scenarios to your teams or even peers, you see those diverging ideas converging to something concrete.
That's how BDD helps you shape that idea. That fuzzy scenario, when validated thru' an engineering "spike", can be useful for product management MRD/PRD/use-case-models/stories...whatever it is that you want to use to drive product development.
And this is where Agile Tester role begins! So instead of doing top-down or bottoms-up product management & testing, try this outside-in approach. Go for it!
My workshop on BDD is about what I term as "Outside-in agile product management". To understand what I really mean by that, here is my slideshare presentation used rarely when teaching from the back of the class during this hyper-interactive workshop.
This presentation was provided by Bill Trippe of Publishing Technology Partners, during the NISO event "Project Management for the Information Community: Managing and Communicating the Process, Session Six," held on Friday, March 29, 2019.
Acorn Recovery: Restore IT infra within minutesIP ServerOne
Introducing Acorn Recovery as a Service, a simple, fast, and secure managed disaster recovery (DRaaS) by IP ServerOne. A DR solution that helps restore your IT infra within minutes.
Have you ever wondered how search works while visiting an e-commerce site, internal website, or searching through other types of online resources? Look no further than this informative session on the ways that taxonomies help end-users navigate the internet! Hear from taxonomists and other information professionals who have first-hand experience creating and working with taxonomies that aid in navigation, search, and discovery across a range of disciplines.
This presentation by Morris Kleiner (University of Minnesota), was made during the discussion “Competition and Regulation in Professions and Occupations” held at the Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found out at oe.cd/crps.
This presentation was uploaded with the author’s consent.
0x01 - Newton's Third Law: Static vs. Dynamic AbusersOWASP Beja
f you offer a service on the web, odds are that someone will abuse it. Be it an API, a SaaS, a PaaS, or even a static website, someone somewhere will try to figure out a way to use it to their own needs. In this talk we'll compare measures that are effective against static attackers and how to battle a dynamic attacker who adapts to your counter-measures.
About the Speaker
===============
Diogo Sousa, Engineering Manager @ Canonical
An opinionated individual with an interest in cryptography and its intersection with secure software development.
Sharpen existing tools or get a new toolbox? Contemporary cluster initiatives...Orkestra
UIIN Conference, Madrid, 27-29 May 2024
James Wilson, Orkestra and Deusto Business School
Emily Wise, Lund University
Madeline Smith, The Glasgow School of Art
This presentation, created by Syed Faiz ul Hassan, explores the profound influence of media on public perception and behavior. It delves into the evolution of media from oral traditions to modern digital and social media platforms. Key topics include the role of media in information propagation, socialization, crisis awareness, globalization, and education. The presentation also examines media influence through agenda setting, propaganda, and manipulative techniques used by advertisers and marketers. Furthermore, it highlights the impact of surveillance enabled by media technologies on personal behavior and preferences. Through this comprehensive overview, the presentation aims to shed light on how media shapes collective consciousness and public opinion.
2. What a user story isn’t
• It’s not a defect
• It’s not an accessibility issue
• It’s not a cross-functional
requirement, and
• It’s not an epic
3. Other types of stories
Epics
• Large stories that need to split
into smaller manageable chunks
• No magic formula about when a
story becomes an epic
• Short on detail – broad brush
approach
• Will take more than one sprint to
develop and test
4. Epic Template
Description
These are large features / stories that will take more than one sprint to implement – try to split where possible.
Add in a description of the feature that needs to be developed, what is the background of this issue
What is the value of this work
Priority
High Medium Low - What is the reasoning behind the priority marking
User Story
• High level / broad brush user story
Approach
• What tools / techniques will be used - Knowledge gather / evaluate viable technologies / design workshop / discussion etc.
Outcome
• What happened?
• Where stories raised – where this happens show the links / references to the story cards and show the epic link reference on the card
Comments
Keep a record of the key events and decisions
Members
Who are the key people that will make this happen
5. Other types of stories
Spikes
• Investigating / researching an issue where the
approach isn’t known
• Start by thinking about how to tackle the
issue; knowledge gather, design workshops
etc.
• Might not have all the answers; you need to
start somewhere!
• Lots of conversations with a range of
stakeholders to understand the issue
• Need to time box and add the outcome / raise
6. Description
These are stories that need investigation / research possible approaches to resolve issues
Add in a brief description in plain English avoiding jargon wherever possible
There needs to be a deadline for resolution
Overview
• What is the high level objective of this piece of work
Approach
• What tools / techniques will be used
• Knowledge gather / evaluate viable technologies / design workshop / discussion etc.
Outcome
• What happened?
• Have cards been raised to action – if so add a link here. And move this card to done
• Or if it’s not going to be taken forward move the card to waste
Comments
Keep a record of the key events and decisions
Members
Who are the key people needed to make this happen?
Spike Template
7. Other types of stories
Defects
• Need to be agreed by the team it is
a defect, not just how we wish it
was working!
• Sets out the impact on the service as
a whole
• Use process flows and screen shots
to explain the issue – step by step
explanation of issue
• Provide revised/improved
8. Defect Template
Description
Only raise a card for a defect when it’s been agreed across the team; QA / Dev / BA / PO.
Must be prioritised by the PO before the work starts (and less priority work dropped!) and must added to the sprint
The description is written by the originator and should contain:
Step by step explanation of the issue
Attach any process flow / screen shots etc. that will further explain the issue
Impacts
• Add the impacts across the service
Acceptance Criteria
• How will you know when the issue is solved
• Use any standards / Definition of done to determine how the service should be performing
Comments
Keep a record of the key events and decisions
Members
Who are the key people needed to make this happen?
9. Other types of stories
Task
• Not a story at all it’s just a card
• A one off piece of work
• Need to have an end date when
action will be complete
• Checklist what you are going to do
• Record the outcome
10. Task Template
Description
These are one off tasks – if they are items that will be re-iterated than new cards need to be added each time (no hidden work). Need to determine
what the card is all about.
Best to try and use SMART (Specific Measurable Achievable Relevant and Time Boxed)
Link the task to an Epic if possible
Estimation
Try to estimate the size of the task
Checklist
• This is a list of the steps to get you to the outcome; in Jira you can add sub-tasks
Outcome
• What is it that you are trying to achieve, what’s the objective, when will you know it’s done?
Comments
Keep a record of the key events and decisions
Members
Who are the key people needed to make this happen?
11. What is a user story
It’s a promise of a
conversation:
13. User story
• A defined user need – this is a must;
why are you doing it?
• Start with the goal; don’t focus on
the “As a user…” syntax
• Describe what the feature will do
not how it will be implemented –
use simple language so everyone
understands the purpose
• Set out the value of the work
What does a user story look
like
14. What does a user story look
like
User story
• Size appropriately; if it can’t be done
in one sprint it’s probably an epic!
• Need to have robust acceptance
criteria through conversations to
ensure you know when it’s Done
• Add in detail as you go along, don’t
try to think of everything straight
away
• Don’t future proof as User Research
may push in a different direction
15. What does a user story look
like
• I - independent
• N - negotiable
• V - valuable
• E - estimable
• S - small
• T - testable
16. Story Template
Description
Every card should have a clear high-level description that briefly outlines the requirements of the card.
Write story using invest (Independent, Negotiable, Valuable, Estimatable, Small, Testable)
Try to link the card to:
User need
Business need
Technical need
User Story
Focus on the outcome / goal of the issue; use the Connextra syntax “As a user… I want.. so that..” if it helps
Content
Where the card requires content, need to be clear what this is and add any screen shots / form of words where appropriate
Acceptance Criteria
The “Given, when, then” format only needs to be used when there are several actions that need to happen in a scenario
Otherwise it’s okay to keep acceptance criteria simple by using a validation / standards documentation
Comments
Keep a record of the key events and decisions
Members
Who are the key people needed to make this happen?
18. Let’s have a go at user stories
We’re going to compare and
improve the Amazon and
Argos website
19. Let’s have a go at user stories
• Get into two groups
• You have £150 to £200 to buy a
birthday present for a child
• You’re not sure what to get
• One group look at Amazon
and the other at Argos sites
20. Let’s have a go at user stories
• Concentrating on the goal of
each activity write a user story
• Think about INVEST
• Don’t worry too much about
the “ As a…” syntax
• Add an happy /sad face about
how you feel when carrying
out the task
The main aim of this presentation is talk about user stores; however I will talk about other stories or cards as well
Defects; where the story hasn’t passed acceptance testing / PO Review
Accessibility; this is about making sure the service works on a variety of devices and browsers
Cross – functional requirement; make sure it conforms with Gov.uk look and feel – lots of guidance on this
Epics; this are just first ideas that need to be discussed and more than likely need to be broken down into manageable chunks
Before going into what a user story is – let’s look how to write cards for “non user stories”
Epics are just big stories
There’s no magic formula about when a story becomes an epic
A good rule of thumb is if it will take one or two sprints to develop and test
These generally are short on detail so a high level/broad brush approach when thinking about the user story
Will need to be split into smaller manageable chunks – so think about the approach you will take to get to the outcome
These are stories where the approach to an issue or problem isn’t know
There needs to be lots of conversations across stakeholders to determine how best to overcome the problem
It’s best to start with a brief description and overview
Think about how you will approach the issue; will it need knowledge gather, evaluation of viable technologies, design workshops or just a series of one to one discussions – all the above or a mixture – you might not have all the answers but you need to start somewhere!
There needs to be a deadline to the work and you will need to add in the outcome; have cards been raised if so moved to done
And if the investigation proved there isn’t any need to do anything the card should be moved to waste (it’s not a waste of time just an agile expression!)
Only raise a defect when it’s agreed by the team that it is a defect – this isn’t when it’s not working how now feel would work better it’s about that what was agreed hasn’t been built
Doesn’t have to be corrected if the PO doesn’t feel it’s a priority
There needs to a step by step explanation of the issue
Set out the impact on the service as a whole if appropriate
Use process flows and screen shots to further explain the issue
There needs to be an end date
Have a checklist of what you’re going to do
And you need to record the outcome of the task before moving it to done
This was proposed by Ron Jeffries
The card is a place to jot down a few ideas – not the detail; it’s a promise of a conversation – it’s a placeholder to talk about the requirement
The conversation is all about collaborating to build what the user needs - this is a continual process and includes the three amigo process to formalise the acceptance criteria
The confirmation is ensuring all the acceptance tests are passed – the software does what the user asked for and that story is truly done
So it’s a unit of work that can be completed in one sprint – too small it’s a task too big and it’s an epic
A conversation between the business (you as a BA) and developer
So it can contain:
A defined user need – it all starts from a defined user need
The business rules; shared task list for non-developer work
Functional scope
High level narrative of the feature
Try to size appropriately to ensure it can be completed within in a sprint – otherwise it’s an epic! - Use story points / Fibonacci; what the team feels comfortable with - it’s guess work and this will get better over time There are many ways to split stories – how long will it take and is it a story or an epic?
Acceptance criteria – try to get these as tight as possible through the conversations, define the boundaries ; can be in gherkin (Given, when, then); need to be agreed as a team, what works for you. How will you know it’s doing what you intended? This will lead to the testing needed.
Keep it simple; don’t try to get everything down straight away no one knows all the answers or even the questions that need to answered – work with stakeholders to ensure the business rules and user needs are set out as fully as possible – remember some of the NFR / standards can form part of definition of done. Don’t try to future proof as who knows what the next round of UR will throw up or what new business rules may need to be implemented Use backlog review to go through stories in detail and close off any open questions – get mock ups, add in BPM etc what ever refines the story
Let’s get into a couple of groups
Get up the Amazon / Argos website – The scenario is that you need to buy your child a birthday present for between £150 and £200…you’re not sure what to get. Concentrating on the goal of each activity write down user stories for what you are doing; Thinking about INVEST, use the template As a … if that’s helpful.
What’s also helpful is to add an happy / sad face to the story so that we can get a feel for the user experience – experience mapping - as this can help determine which stories to prioritise to
Let’s get into a couple of groups
Get up the Amazon / Argos website – The scenario is that you need to buy your child a birthday present for between £150 and £200…you’re not sure what to get.
What story as a group are we going to pick to improve the site or create an even better buying site?
Concentrating on the goal of each activity write down user stories for what you are doing; Thinking about INVEST, don’t worry too much abut fitting the stories into the “As a user” template.
What’s also helpful is to add an happy / sad face to the story so that we can get a feel for the user experience – experience mapping - as this can help determine which stories to prioritise on the back log.
After 15 mins let’s share what we have and compare the UX. Get someone to feedback and explain the thinking behind the story. As a group does it fit the INVEST model
What story as a group are we going to pick to improve the site or create an even better buying site?
