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.