I'm pretty new to application development at a large company, and I've only experienced bad jobs in the past. The user stories created by my business analyst often feel too vague for me. For instance, one of them is just, 'Create an endpoint that can be hit from Orkes in the web service to get orders from the orders table.' This leads to team members going off and writing a whole bunch of code components like controllers and orchestrators without clear direction. Is this typical in the industry? It feels like I'm left to figure things out on my own without much guidance.
5 Answers
Ultimately, what really matters are the acceptance criteria. They should clearly outline what is expected from both the requester and the developer. When everyone understands the acceptance criteria, the development process can move smoothly, even with high-level user stories.
Our process involves initially creating user stories, which are then refined into developer stories with precise design tasks and acceptance criteria (AC). It ensures everything is agreed upon by the BA, QA, and developers before getting assigned. This way, the story gets vetted thoroughly, reducing misunderstandings.
User stories really serve as placeholders for discussions. They should clarify who wants what and why. For instance, 'As an admin user, I need to limit access for security reasons.' Then the team can dive deeper into specifics like what kind of access needs limiting. The actual implementation details should emerge from those discussions, not be dictated from the start.
That makes total sense! It feels like there's an expectation to just build based on the initial vague description.
Yes, this situation is unfortunately pretty common, but it’s not ideal. User stories should really have three main components: the persona (who is doing the action), the action itself, and the reason behind it. For example, a better story might be, 'As an admin, I’d like to see a list of orders so I can quickly check their status.' Beyond just the stories, you also need detailed acceptance criteria (AC) that specify the inputs, expected outputs, error handling, and user authorizations. If your stories lack these details, it's crucial to have conversations to fill in the blanks. For instance, specifying things like 'GET /orders should return a JSON response with a specific schema' would help a lot.
Thanks for the insights! What you described is exactly what I've been wanting. Those details would make everything so much clearer.
Generally, user stories shouldn't include specific implementation details. They should focus on the functionality desired, like 'As a user, I want a feature to do X so that Y happens.' It's all about setting up a conversation around what needs to be built without dictating how to build it. That's how I've learned to approach them, and it seems to work well.
I think you hit the nail on the head! It shouldn’t be the developer's role to figure everything out based on vague stories; there should be a clearer breakdown of tasks.
Got it, we definitely don't have that level of detail—it’s just a single step in my case.