u/Positive-Skin-2839

I'm continuing my battle within my IT team to write good-quality user stories.

Some of my challenges:

1. Until recently, we had Business Analysts and Systems Analysts as two distinct roles. Each side has a take on what a proper user story is.
2. We really write use cases more than we write user stories.
3. Our stories are often 8+ (sometimes easily 12-16) ACs written in the Given/When/Format and we also add in Dev notes and QM notes into some of the ACs.
4. We also have long technical specs in our stories as well.
5. DEV/QAs have told us they don't read our stories.
6. We are allergic to breaking down stories, so we make them crazy long.
7. We have no definition of a "good" story, so we use length or "that story is too detailed, so it's not good" as a measure of a good story.

An opportunity has arisen to review how we write user stories, but my team keeps trying to define "good" primarily by point #7.

So, if anyone has come across this challenge of trying to change people's minds on stories and has any feedback, let me know.

I'm aware there is no one-size-fits-all solution, but I also feel like ignoring industry and best practices, like we're doing right now, is not the way to go.

Hello,

I'm a BA, and I joined an organization a while back. Since day 1, the way that "user stories" are written has caused me physical pain.

Here are my observations of a typical story we write:

1. We don't actually write user stories; we really write use cases.
2. We have 8-16 Acceptance Criteria per story
   1. Each AC uses Given/When/Then and, if "appropriate," technical notes and notes for QMs.
3. We throw in technical specifications on top of the ACs into a lot of user stories, making them even longer and hard to follow.
4. We are allergic to breaking down stories into smaller chunks
5. We are defining what makes a good user story on the "length" or if it's "too much detail" or "not enough detail" instead of looking at the qualities a good user story should have.

Other challenges:

1. There is very little education on writing user stories. The Systems Analysts have a perspective on it, so they write their user stories one way; the Business Analysts have a different perspective and write theirs their way.
2. We've heard complaints from Dev's and QM's about our stories, but we don't actually engage them in any discussions about how to improve what we're writing.

There is an opportunity to change the way we do things right now, and with the challenges above, I'm getting a lot of resistance, so I'm looking for info.

So my questions to you as Developers:

I work on a team that handles both AI and non-AI development/enhancement.

1. What do you need from a user story?
2. What makes a good user story to you?
3. Would something like a "dev notes" section help, where it has like a concise list of what you need to do?
4. Any suggestions?

Hello,

I'm a BA, and I joined an organization a while back. Since day 1, the way that "user stories" are written has caused me physical pain.

Here are my observations of a typical story we write:

1. We don't actually write user stories; we really write use cases.
2. We have 8-16 Acceptance Criteria per story
   1. Each AC uses Given/When/Then and, if "appropriate," technical notes and notes for QMs.
3. We throw in technical specifications on top of the ACs into a lot of user stories, making them even longer and hard to follow.
4. We are allergic to breaking down stories into smaller chunks
5. We are defining what makes a good user story on the "length" or if it's "too much detail" or "not enough detail" instead of looking at the qualities a good user story should have.

Other challenges:

1. There is very little education on writing user stories. The Systems Analysts have a perspective on it, so they write their user stories one way; the Business Analysts have a different perspective and write theirs their way.
2. We've heard complaints from Dev's and QM's about our stories, but we don't actually engage them in any discussions about how to improve what we're writing.

There is an opportunity to change the way we do things right now, and with the challenges above, I'm getting a lot of resistance, so I'm looking for info.

So my questions to you as Developers:

I work on a team that handles both AI and non-AI development/enhancement.

1. What do you need from a user story?
2. What makes a good user story to you?
3. Would something like a "dev notes" section help, where it has like a concise list of what you need to do?
4. Any suggestions?

Hi Everyone,

So I have always kept my calendar visible to everyone. I don’t share all the details, but you can see the topic/subject.

I think it makes things significantly easier, when trying to find meeting time. I use tentative on my calendar to show that I can be available if needed and use busy for meetings and focus time.

In my current organization, everyone hides their calendar visibility. So all I see is purple, I literally have to message some stakeholders 2-3 times a day and be like are you available for this time, if not when can you be available.

I’ve had people message me and be like “You know we can see your calendar right? Here is how to turn it off incase you don’t know”.

So, thoughts?