nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to write good user stories?

badi

Hi folks,

I am an intermediate level JIRA user and a student doing software development. I am interested in learning more about project management and started to dive deeper into product management. I find some articles on the internet about writing BDD (Behaviour Driven Development) to make good user stories and how to apply the I.N.V.E.S.T mnemonic to user stories.

I particularly find it hard to make independent and small user stories.

As an example consider the following two user stories:

1# Story

As a user, I want to rotate an object, so that I can view the object from different angles.

Acceptation criterium

GIVEN I am on the main screen AND an object has been placed, WHEN I select this object, THEN the 'rotation' button has to be visible to me.

GIVEN I am on the main screen AND the 'rotation' button is visible WHEN I push that button and I make a circle gesture with my finger on the screen THEN the selected object has to rotate to the angle where my finger is moving.

Sub-tasks

- Design the knob for rotation.

- Create functionality for the knob.

- Create functionality for rotating the object.

-----------------------------------------------------------------------------------------------------

2# Story

As a user, I want to delete an object, so that this object won't disturb my view.

Acceptation criterium

GIVEN I am on the main screen AND an object has been placed, WHEN I select this object, THEN the 'remove' button has to be visible to me.

GIVEN I am on the main screen AND the 'remove' button is visible WHEN I push that button THEN the selected object has to be removed.

Sub-tasks

- Design the knob for removal.

- Create functionality for the know.

- Create functionality for deleting the object.

----------------------------------------------------------------------------------------------------

Writing these stories confused me.

Because both of these stories are dependent on the following stories: As a user, I want to place an object... and as a user, I want to select an object...

Placing an object and selecting an object are different stories in my document. And the knobs with are supposed to display in a menu are created and designed individually in these stories is that the correct way? And are these sub-tasks making sense for the stories?

I am experimenting with writing good stories and I would like to have feedback on it, so I could learn and improve.

Thanks for reading and I hope you will have a nice day.

Comments

John Theofanopoulos_mko6dl

There is not 'good' or 'bad' definition for user stories.

It all depends on your company and the way they are used to work.

Example, I'm working for a software development company and depends on the project I might go as much detailed as possible or not.

Typically on a user story, you want to add why this user story needs to be done (me as a user...), acceptance criteria and then I also some times add detailed information such as design URL, image of a wireframe, where to find something in code etc.

If you have a product and wireframes for it, it's always good practise to add the image that your user story is referring to.

badi

Thanks for replying and helping.

The main thing that I do not really grasp is the INVEST guideline. Making independent stories is hard, how can I make independent stories if they have pre-conditions in the acceptance criterium. For e.g. to rotate an object. The object has to be first placed and selected. But those are different stories by themselves. If I combine them to one story, the story becomes too big.

John Theofanopoulos_mko6dl

In that case I would suggest you to come up with a template for user stories and gather feedback from your team.

I understand that some user stories can come up as long - however for that case you'd have to break down the user story.

Usually what I do for software, is create a user story which is high level.

Then I would create the technical task and link it to the user story (task will have more technical details but it will always link to original user story with high level feature - you can call it 'business' level explanation on the user story).

Then if I need to break it down, I'd use sub-tasks in the task.

Ste Wright

Hi @badi

These aren't hard-and-fast rules - stories can be flexible and it will depend on the team or project you work on.

For example, some teams will use stories for user-based outcomes or value - and tasks for infrastructure or non-functional requirements. Others will write technical stories - which might differ in their structure but are still fine to give original foundations for customer value deliverables.

With this in mind, INVEST is a great starting point but just a guideline. For "I", stories should be as far as possible independent from one another, but that is not to say there are no dependencies or prioritised order - you need to create the button before you can rotate it.

I also find SMART works well for acceptance criteria - Specific, Measurable, Achievable/Assignable, Relevant and Time-based. Again these can be flexible - GIVEN / WHEN / THEN is a good starting point - but our teams just use bullet points with a YES / NO based function against each point.

Ste

Sharon King

Hi @badi
By now hopefully you've encountered the technique of user story mapping to assist in solving the problem you have with interdependent stories.
Its a great way to visualize the journey a user has when interacting with a product. It also assists in determining the sequence order that helps in decision making regarding how to prioritize your stories (the ordering of your backlog).
The key to being agile is the conversation between members of the team. Having just enough information (the detail of the story) helps to guide and drive the quality of the conversation so that the intent is not just understood but also easily remembered with minimal need to reference documentation for answers. The best user stories are those able to achieve this goal. A defined Definition of Ready, helps with managing the expectation of what "just enough" is for the team the stories are for.

Product road-maps visually aid product owners outline their plan for the year ahead. User story maps help the team understand the big picture, making sense of how features are selected for implementation.

Good luck with your studies :-)

Teagan

Hi @badi

I wrote this blog post called How to Write Good User Stories in Agile Software Development last year.

I hope it provides some perspective!

Teagan Harbridge
Product Manager - Easy Agile

Konstantin Virolainen _Crosstown Tech_

Lots of good tips here already — story mapping, SMART criteria, templates… all help keep things consistent.

We wanted to take it one step further and make the writing part easier for everyone. The idea was to set our own best-practice rules (there’s no one-size-fits-all) and have Jira quietly check stories against them, suggesting fixes when needed. Hopefully, that means less back-and-forth and fewer “what did they mean?” moments.

That’s how we ended up building AI Copilot for Jira — curious if something like this would help your team too:
https://marketplace.atlassian.com/apps/1238320

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

agile

bdd

atl-orange

story

acceptance-criteria