What is best practices in writing user stories? how many acceptance criteria should normally maximal a user story have?
We have people from business who unfortunately create large user stories with more than 15 user stories, some of them complex some easier to handle, but it ha no end if you as developer see the user story with 15+ acceptance criteria in it.
Which is best practices? how do you handle this normally?
While people from the business may be creating user stories, you, the Product Owner, remain accountable. These business people are your stakeholders, and what could help is that you invite them to a meeting to get your arm around what is needed and take ownership. Then, set up some Product Backlog refinement sessions with your team to better understand the work and break the large ones down into smaller pieces of work that can fit into a Sprint. It's okay to invite the business to a refinement session as well.
There are no best practices for complex work. Typically, I coach teams to have 3 to 5 acceptance criteria for a user story, but everyone's context is different.
We have people from business who unfortunately create large user stories with more than 15 user stories, some of them complex some easier to handle, but it ha no end if you as developer see the user story with 15+ acceptance criteria in it.
Which is best practices? how do you handle this normally?
They've created work which is not Ready for Sprint Planning and which the Product Owner struggles to account for. The Product Owner should either remove it, or if it is deemed valuable enough, help the Developers refine it to the point that they are satisfied it can be Done in a Sprint.
Product Backlog refinement is an act of ongoing curation and the art and science of making work Ready for Sprint Planning.
When the Developers are in Sprint Planning, the question should never be "Can we do this work we are being asked to do?". Rather, the question is "Should we? Should we do this work in order to meet a good Sprint Goal? What would that Sprint Goal be?"
Which is best practices? how do you handle this normally?
Having multiple acceptance criteria should not be a problem as there might be different scenarios to be validated (I would say the more the merrier as it gives better clarity).
From your description, may be what is written is an Epic (large story) which needs to be broken down further. Use the SPIDR (Spike, Paths, Interfaces, Data and Rules) to break them into smaller manageable stories.
Try to use the criteria INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) to validate the sizing. Key thing is that every story should deliver a business value at the end of the sprint (split vertically rather than horizontally).