User Stories
User stories are often used by IT teams to understand requirement better
Just think of all the users who will be using your product or services
All of them have their demands
Few would be unique
Some would be similar but not exactly
These end users are called Personas and the stories are written by empathizing with these personas
You always try to find the balance between all the stories that could help you in achieving your project goal
And in your journey you know that these may change over time
As said these are stories that are based on experiences of people
The experience tends to change based on different dynamics around us
These are the 10 points to remember while you deal with such user stories in your system
1. User stories are not requirement documents
a. A User story is a one liner statement written in an end user’s perspective
b. You could write awesome extensive requirement documents if you want to with the help user stories as it helps you in triggering the conversation
2. Without acceptance criteria your story is useless
a. We all are different and we see things differently
b. Its important to share the same perspective to confirm the done-ness of any story
3. Without value your story is a gossip
a. Business value is a key & in the end when a story is implemented then it actually solves end user’s problem
4. Learn to put constraints on your stories
a. There could be an endless expectation that one could fulfil in an story
b. We should limit such expectations by breaking it into smaller stories and by clearly defining acceptance criteria
5. How big a Story should be?
a. A story should be as big as you want – it is called EPIC
b. But the idea is to break it or slice it into smaller pieces that could get implemented into a sprint duration
6. Finding relation between hours and story points
a. I see it as a crime when any team does it
b. Story point is a relative sizing mechanism where its definition is exclusive to one team
c. It is based not just on efforts but also on uncertainty and complexity so stop doing it if it is the case
7. Who writes the story?
a. Product Owner writes the user stories as he or she is responsible to maximize the value of each increment the team delivers at the end of every sprint
b. Product Owner interviews everyone and Ofcorse checks with development team before agreeing on the correctness and completeness of the story
8. Please do not use diplomatic language while writing stories
a. There should not be any hideous detail
b. The idea is to explain your point well to the development team so that there should not be any surprises when team implements the story and demonstrate it in the review meeting
c. Development team loses the trust if Product Owner backs off from the mutual agreement
9. Which story to do and when?
a. Product Owner position the stories in the backlog by prioritizing all of them based on delivering the maximum value first and also injecting the maximum risk items from the top of the backlog
10. In which meeting do we write, discuss and finalize user stories?
a. Any project starts with writing the stories first
b. These stories are discussed several times throughout the project journey as the goal is not to have any open questions
c. Do spike or anything but we want clarity on the stories that we are going to work on
d. Just make sure that when a story gets qualified for sprint that time the team should have utmost knowledge so that they are confident enough to implement it rightly
That’s all.