Summary: YOUR BEST AGILE USER STORY

1. Creating a user story
1. what is a user story
1. “As a [persona], I want to [do something] so that I can [realize a reward]”
2. As an HR manager, I want to match an open position’s required skills with quiz topics so I can create a quiz relevant for candidate screening.”
2. organize stories: 
epic story -> user story -> test case
1. Examples for epic story: “As the HR manager, I want to create a screening quiz so that I can make sure I’m prepared to use it when I interview job candidates.”
2. Knowing If You Have a Story (những thứ cần có để viết 1 user story)
1. Who are we talking about?
1. the twin anti-poles of design failure:

1. 1. Do precisely what the user asks => no one uses the product
2. 
2. assuming that you know the user and ignore them => no one uses the product
2. persona: be they buyer and/or user of your product
2. What do they want?
1. Example for Enable Quiz:
1. ‘Hiring technical talent.
=> too broad, abstract
2. ‘Screening technical talent.’ => probably about right
3. ‘The HR manager preparing a new quiz from an open job description.’, ‘The HR manager sending notes on candidates to the functional manager.’=> too detail
3. Designing Better User Stories
1. What’s the right level of detail?
1. Example: 
1. ‘I want to properly screen engineering candidates so my company can get the best possible hiring outcomes.’ => too board
2. ‘As Helen the HR Manager, I want to screen an engineering candidate, so I know their skills profile.’=> more specific
2. Use storyboard to explore an epic user story (images with users, actions and background)
2. What’s their reward?
1.  testable reward
2. example:
1. so I know their skills profile => can not test
2. so that I can make sure I’m prepared to use it when I interview job candidates => testable
4. Testing User Stories
1. What are we testing?
1. the most important thing is to a) draw a clear distinction between usability and motivation and b) understand the relationship between them.
2. BJ Fogg’s curve
2. How do we test stories?
3. When is a story done?
1. you just can’t predict (with any consistency) what’s going to be valuable for the user. Therefore, you need to work with testable ideas and closed-loop experiments to see if you’re right or not.
2. Ideally your stories begin with some kind of observation about your user and the problems (jobs, desires) they have. Then you come up with a testable formulation of how you’ll know if your solution idea is really better than what they have now. 
5. Developing with Stories & Story Maps
1. Who writes user stories?
1. Product Owner (PO)
2. But take care of Some problems
1. 1/40: people only understand 1/40 what you said
2. We Measure our Efficiency Locally: A certain part of us just wants to know in the simplest possible terms what our job is and how much of it we have to do. We crave certainty and an immediate sense of accomplishment. 
1. Unfortunately, you can’t build software that’s valuable to users this way (at least not with any consistency). If you don’t co-create stories with your team, they’re just not going to feel like they own them and their work won’t be as thoughtful. 
3. You Don’t Have All the Best Ideas =>PO/story lead should run story writing workshops
2. How do you use stories within a team?
1. story map: (a tool that formulate the stories together and make them highly visible to the team) (image)
1. first stripe (0) defines the x-axis of the story map and represents the customer/user journey. It’s best built with storyboard squares.
2. The y-axis describes relative priority, so stripe 1 is higher priority than stripe 2 and so forth.
3. How do you use stories day to day?
1. use stories should follow the Bill Wake’s INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable.