What is a user story

In Agile methodology ‘User Story’ is a unit of work that should be completed in one sprint. Smaller than that it’s a task, more than week(s) of work is Epic or Theme.

Check-out our previous post for 25 example of  user stories templates

The agile recommendation is to break down a set of user stories into smaller ones, containable into a single sprint duration, or ideally, a user story shouldn’t last more than a week.

One thing to keep in mind is that some of the agile “best practices” are to avoid having child stories, it is not a good recommendation to have user story in nested hierarchy, as that is also hard to model with stickies on a whiteboard.

There are some tools providing support for nested hierarchy of user stories, but you should avoid it. Keep the stories as a flat list, all at the same level.

How to write a user story

User Stories doesn’t need to be this format. The user story format is not a requirement of Scrum. but it helps to force the story writer to articulate those important three questions.

• Who are we building it for, who the user is? — As a <type of user>
• What are we building, what is the intention? — I want <some goal or objective >
• Why are we building it, what value it bring for the user.? — So that <benefit, value>

User story Template

Having a template for a user story, provides a good guideline. It helps avoid common problems and pitfalls. With a template, you get to see what user role the story is for, what they want to be able to do, and why. Then you as PO and the developer[Team] get to figure out how to accomplish that. Engineers and POs do not use the same language/not understanding each other. This template force some a common principle and help to understand what should be written to be understood well by both parties

User story template describes both the requirement and the value to the stakeholder. There is no specific format for defining a user story in agile, agile doesn’t force any kind of template for a user story.

The concept of writing a user story is to start a conversation around the story, and the mutual understanding that we try to build, the value we want to offer to a user and how the user will utilize it.

Do not write a user story for the sake of writing it. People tend to think that they’re done with writing a user story when they managed to fill in the blanks in the template, but someti it just doesn’t fit.

This is a very bad example of user story and agile world is full of these user stories

Practical example of user story Template

Screenshot bellow is the real story from our sprint, it is shown as is without any modification, idea is to show how we are using agile and what is our template of user story look like.

User story bellow is a result of feedback we receive from a customer, 80% of the sprint content is based on direct feedback from customers.

Our prioritization is based on the value proposition for the requested feature or feedback.

How we receive user stories

We are in direct contact with customers via phone call, skype, twitter, email, uservoice and real-time chat[intercom.io] . We instantly forward the email to our Yodiz project. In Yodiz you can create user story, issue and epic via email, please check the link here.

Why you should write a user story

As a Product Owner (PO) when you receive a user story from any source you should be asking yourself following questions

1) Why are we doing this, what is the business or technological gain?

2) What is it for, who will be user actually using it, remember the 80/20 rules ?. If you are spending too much effort on providing the feature which is either not requested by many users, or doesn’t add much value.

3) What value does it drive, what is monetary, user, or UX gain of that user story?

4) what’s your estimates on time to implement?

5) what are the acceptance criteria or CoS (condition of satisfactions)?

6) what testing will be needed?

7) What support can you give?

8) what is your marching order, does the story fit well in the marching order?

Product owner and the team should decide on what they feel is the most appropriate way to describe the work that needs to be done. As team know how part and PO knows the what part

What user story is really for

User Story is only meant to describe a feature, but not describe how to implement it, meaning leaving out the technical aspect, it should describe the behavior or flow from user’s perspective.

A user story is basically a use case. What do your users need the software to actually do? A story should be a unit of work that a team commits to in a sprint. Whether or not that unit requires subtasks should be up to the team.

Story points for user story estimation

Sizing of the story point of early adaptors of the scrum, as sometimes a story will be small enough if we do too much slicing vertically, other time it get way too bigger, as we keep on stuffing the feature in one single user story.

Reason of having story point

This is why we have story points. The points are a fuzzy measurement of how big or small a story is, and should be estimated by the engineer(s) who are implementing it or someone with superior knowledge about the work. In organization/team there should have a standard scale for story points measure, so you can compare multiple stories and say and have some reference like you are able to say that those seem like a similar amount of work like that user story.

More often used is Fibonacci numbers, which is fairly standard. The points don’t really “mean” anything, though, they don’t equate to the amount of time spent or effort for implementation, its simple way of calculating a relative complexity or measuring to get to point A to point B.

Definition of Done (DoD), Acceptance Criteria or Condition of Satisfactions (CoS)

As you fine-tune your estimation, the team should be able to reliably pick up as many stories as they can handle. If your process is working well, that number will probably slowly increase over time, but it take 5–10 sprints to master this technique.

You must define your Definition of Done (DoD) for stories, acceptance criteria or condition of satisfaction (CoS ) . This helps set expectations within the team as to when a team should consider something done. It also help to write detail level of test cases other advance of writing CoS, DoD or acceptance criteria is, you force yourself to think like an end user. What comes out of this approach is much different than writing user story as a PO

Characteristics of a User Story

• A story should be complete and big enough to provide a user with some value. The user story should be user-centric, normally people write user story which is too much centric around component or system aspect, when writing a user story, we should focus on what the user is doing or getting out of the story.
• The goal is that when the user story is done, the user can do something of value to them.
• Group user stories which offer a feature in the same domain, or its good to group a certain feature or use case into a single Epic or even multiple Epics. Ideally you’ll break up your features in a way that you can launch into production parts of the feature independently from the whole, but its not always possible.

Grouping user stories

Epic is simply a story that is too big to fit into a single sprint or too complex to estimate. To cut off or slice horizontally a bigger story/epic, is highly dependent on the team itself. Not all stories necessarily need to fit under an epic

Once something you find which is above the threshold of a user story, it should be broken down into more manageable chunks.

Epics are like chapters in books, themes are like a collection of books on the same topics, while the project is a library which contain all those books.

User story grooming session

It is highly recommended to go through the user stories with a group of stakeholder and some of the team members. It help to describe what’s needed in order for the item to be ready for development and to which priority.

Sprints are meant to allow you to deliver finished parts of the end product. As simple as they may seem, it requires a proper planning, it require to have perfect input and need to specify acceptance criteria.

How to run grooming session for the user stories.

1. Send a recursive invitation for grooming session. Depending on your sprint duration, if you are having two long sprints then it’s ideal to have grooming session every month or every two week, it should while sprint is in the middle.
2. Prioritize the backlog as good as you can, ask the participants to through the userstroies before coming to meeting, so there can be a detail level of discussion
3. You can invite people from technical team, not all members need to be there, but some senior memebers, architect or someone with good knowldlege about the user story in quesiton should be invited, then there should be people from business, sales or stakeholders, the internal customer they people who requested those user stories.
4. It is important to run the meeting as timebox for 1 hours, more then that its waste of time, you can have biweekly shorter meeting, its not a good idea to spend 3 hours for grooming session, as its not very productive.
5. Go through the user stories in detail, try to finalize the open questions, perfect your mokups and describe and verify your user flow.
6. If budget is available order the lunch or coffea/cake
7. Take meeting notes and write clear action points like what to be updated by who, etc

INVEST

Last but not least, we can not close the discussion about user story without mentioning the INVEST

Slice horizontally the user stories by using INVEST acronym

• Independent — Can the story stand alone by itself ?
• Negotiable — Can this story be changed or removed without impact to everything else?
• Valuable — Does this story have value to the end user?
• Estimable — Can you estimate the size of the story?
• Small —Is it small enough?
• Testable — Can this story be tested and verified?

Conclusion

How you write a user story, what is the most difficult thing to overcome when writing a user story.