The need for precise documentation often is the result of handoffs between organizational groups, e.g. departments.
So, my bet is: in your company, QA is organized in a separate department?
Scrum - as defined in the Scrum Guide - defines a team as a cross-functional group that can deliver valuable product increments without depending on the rest of the org.
The consequence of this is: people with test know-how are part of the same Scrum team as the developers. There is no separate department for QA in that model.
Of course, as a developer, you usually don't have the decision making power to change organizational structure.
But even if there is a separate QA department: if devs and QAs collaborate on a daily basis, the need for comprehensive documentation can be reduced.
Oh, I always imagined QA being part of the Scrum team (ie. daily communication, attend all ceremonies, etc). If we also assume that they are then involved in grooming, they'll have a say in defining what the story's expectations are. All that is fine and good, but as time passes I'm sure some of that context will be lost so signals could get mixed.
I'm not advocating for overly precise specification, but just enough!
What I've seen a lot in the past are stories that are one or two sentences that are asking for full login support with error handling and multiple sign in options. That's when things get hairy as we transition from spec, to implementation, to testing and acceptance.
One counter argument there would be breaking up stories so they could be effectively captured in a few sentences 🙂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The need for precise documentation often is the result of handoffs between organizational groups, e.g. departments.
So, my bet is: in your company, QA is organized in a separate department?
Scrum - as defined in the Scrum Guide - defines a team as a cross-functional group that can deliver valuable product increments without depending on the rest of the org.
The consequence of this is: people with test know-how are part of the same Scrum team as the developers. There is no separate department for QA in that model.
Of course, as a developer, you usually don't have the decision making power to change organizational structure.
But even if there is a separate QA department: if devs and QAs collaborate on a daily basis, the need for comprehensive documentation can be reduced.
Oh, I always imagined QA being part of the Scrum team (ie. daily communication, attend all ceremonies, etc). If we also assume that they are then involved in grooming, they'll have a say in defining what the story's expectations are. All that is fine and good, but as time passes I'm sure some of that context will be lost so signals could get mixed.
I'm not advocating for overly precise specification, but just enough!
What I've seen a lot in the past are stories that are one or two sentences that are asking for full login support with error handling and multiple sign in options. That's when things get hairy as we transition from spec, to implementation, to testing and acceptance.
One counter argument there would be breaking up stories so they could be effectively captured in a few sentences 🙂