When we are focused on getting things done, this may not even be our core focus as to what is user story and what is not. We probably don’t even pay attention to it as our focus is on “how”.

This is really a question you want to think about when you are

• Software Development Manager
• Product Manager
• Project Manager
• Business Analyst
• Quality Analyst
• And specially when you are managing a team that includes one or all of above.

When I started our software development firm, my focus was on ‘how’ — and there was no distinction between tasks developer wanted to do and tasks clients were asking for. It was all common pool. This went on for few years. Just like every small team or start-up, it was all over — Excel files, Google Spreadsheets, Emails.. This all did not mean there was lack of efficiency. Actually you can be more efficient with smaller teams for smaller projects — but when you are managing larger projects and bigger teams, you need right tools and better processes and that’s when we need to start thinking about what is ‘not’ a user story.

In Azure DevOps or Jira — a User Story can also be called ‘Product Backlog Item’ (PBI). In golden times, the user story was called a ‘requirement’ or user requirement.

What it is not:

• User Story is not a Task. If you are a developer or have strong technical background, you want to hammer this in your brain. The stuff we do as developer, like — create database tables, taking backups, add that login form, secure api, validate email- this is not a user story. As a developer we think in terms of tasks we will have to perform and we describe those and put into DevOps as user story. But those are TODOs or TASKs and not user story.
• User Story is not HOW. A back-log item or story should not describe how some feature will be implemented. So whether you will create a new drop down or new button or add an API etc. is all details of how you will do something.
• User Story is not a Feature. While user story does not have to be too granular like a task, it should not be too broad like a big feature either. If you think of Google Site, think of size of the story like “user should be able to search the internet”.
• User Story is not always assignable to single programmer: In small teams, and specially when there are those magician programmers in team — you can certainly assign a story to a developer. But when the team gets larger and there are more specialists, a single programmer won’t be able to complete a story by her/himself. A story will need a front-end programmer, a database designer, an API person — and in this case the story remains assigned to BA or Lead.
• BA or Manager does not create tasks: Lead or Manager should not create tasks under any story. Tasks describe “how” a story will be implemented. And it is not BA or Manger’s responsibility to know that. Developers who are working on the story would create there TODOs or Tasks under the story.

What it is:

• User Story is WHAT (not HOW): When you read it, it should sound like what end user wants rather than how it will be implemented. Examples — 1) User should be able to login with Email and Password 2) Admin user should be able to see list of all application users 3) Admin user should be able to maintain/define roles using pre-defined permissions
• User Story starts with ‘User’: Notice that user story starts with ‘user’ — and that is ‘end user’. What ‘end user’ should be able to do is the focus. It is not about what developer should do.
• Product Backlog Item is more encompassing: Previous definition may limit a system because system needs to have many features that are not visible by user. A user story could be 1) System should purge the user history records older than 3 months. 2) System should keep a log of user’s login activity for past 3 months. These types of stories are client’s requirements that end user care less about. Hence, some processes call them PBI instead of user story.
• PBI/Story is assigned to BA or Lead: In many teams it is common practice to assign a story to programmer or developer. This is okay as long as it works and when there is no luxury to have a full-time BA or Lead in staff. If you have BA or Lead then they are the one to assign to story. BA/Lead is responsible to deliver it to the stake holders.
• Developer creates their tasks for each story: Developers will create their tasks for each story and provide estimates for what it will take. It is also okay to create task bucket initially for effort and then divide it further in future.

Story & Bug:

A story is a desired behavior that a system or application should have.

A bug is an undesired behavior that a system or application has that needs to be corrected. But the way a bug should be managed in project management tools can be same as a story. Bug may also need multiple team members and it can have multiple tasks done by different members.

A story is supposed to bring certain benefit to the user or the system.

A bug hinders or obstructs the benefit that a story brings.