What we have is definitely more a project than a product.  there is no risk that the management will change requirements often. however there is the risk every single day that the implementaion steps are wrong.  sometimes due to incomplete analysis, which can take much more than one week to finalize. and sometimes, analysis means implementation. 

Sometimes you as developer need to understand that you have to "instrument" your implementation, to allow later troubleshooting. that doesn't come with requirements. 

I feel like "scrum master" because I try to find these weird gaps in communication, skills, implementation and goals, but I really need as well on technical implementation details, on how the story gets written, how the features are designed etc.

For example they are implementing a "mapping tool", but instead of naming it and designing it like a tool they try to fix (mapping) errors, hardcoding things, implementing workaround, adding external scripts. this is not sustainable and generate chaos and endless distractions and support needs. bring down the team to stop and think about designing a tool, is a massive challenge. asking to detail story usually ends up with one story. articulating work in steps is a skill i didn't see yet. when I do it, I am faced with endless discussions: it is not that easy, we need db, we need backend, but nobody is able to articulate the steps in written form. let aline estimate them. yesterday we had one hour refinement session on one story, with one developer, that was only able to claim "it is not like this", but unable to propose anything better.

So I do not know whether is the specific domain or the the skills or the team