We are using agile scrum methodologies for developing and maintaining a product. Since we are a product company, we do not work with customer directly on day to day basis, but instead communicate with BA who gives us the requirement. We are facing following challenges and wondering how to overcome them.The product we are working on is complex and the BAs and the team is relatively new. When we get the requirement it is very high level. The acceptance criteria is also very high level and involves lot of discovery during the sprint. There are many touch-points which were never considered in the acceptance criteria and they always come up when the developer looks at the code. Due to this the sprint planning becomes very hard and takes away lot of development and QA time in discussion with BA on what should happen for each scenario. Is this acceptable in agile scrum? If so, how can we plan in a better way given very little clarity on WHAT has to be done. Most of the times if we are unable to complete the work in a given release, additional teams are brought in to complete the work and this complicates it further.I believe most of it is due to very little documentation and whatever we have is scattered. When a team member leaves the company, he takes away the knowledge and due to little or no documentation, the new team member (BA) has no where to refer to, and due to this the entire team suffers. So how much documentation is essential?In this case, is it the responsibility of the BA to give proper acceptance criteria or  the scrum team's(BA is also part of our scrum team) responsibility to navigate through such difficulties? The developers and the QAs are always in a time crunch due to the discovery process involved during the sprint. The quality also suffers due to this.We also have to spare additional capacity for the bugs, customer cases. So at the end of it, it is usually the developers and QA who have to put extra hours to meet all the commitments. 
Agile Scrum - Importance of requirement gathering and documentation and suggestions to improve
agile;scrum;documentation;requirements management;changes
Is this acceptable in agile scrum?Define acceptable. In some environments, it's fine. In most, it is prohibitively problematic.That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to the codebase. So while it's not great to have ill-defined feature requests, it's unlikely you'll be able to fix that.So how much documentation is essential?None.I am perhaps in the minority here, but I find documentation - especially over the long term - to be less than worthless. Documentation is a poor communication method. Many people are bad at making it. It doesn't allow you to tailor your message to different target audiences. It doesn't allow interaction to clarify ideas.Worse, it's invariably incorrect/out-of-date. So not only did you spend a bunch of time and effort making these documents, they're actively lying to your staff.In this case, is it the responsibility of the BA to give proper acceptance criteria or the scrum team's(BA is also part of our scrum team) responsibility to navigate through such difficulties?It varies. To me, BAs (and other stakeholders) don't get to dictate what is being done in a sprint. It is an agreement between the team and the stakeholders made during sprint kickoff. That kickoff meeting should be hey, I would like XYZ feature. Okay, what does that mean? Do you need Foo? sort of back and forth until everyone can agree what work is going to be done in the sprint, usually in the form of In 2 weeks, Bob will be able to open the App and order a Pina Colada.We also have to spare additional capacity for the bugs, customer cases. So at the end of it, it is usually the developers and QA who have to put extra hours to meet all the commitments.Why?You're negotiating with stakeholders during sprint kickoff about the commitments you're taking on, right? If you commit to too much, then that's what you get.If you get told what you're doing this sprint, then maybe you should do agile.