Hi Igor. Good article! As an agile coach and Scrum Master, I almost agree to everything you wrote.
There's one thing I maybe see a little bit differently: user stories are originally intended as a "promise for conversation", as Alistair Cockburn has described it. They are not primarily used as specification.
So my ideal scenario is: the PO meets with the devs and discusses story ideas. They write down "just enough" so that everybody has the same understanding. "Just enough" is adjusted in the retrospective.
That's interesting... So in that model, stories are slim and describe the general ask without too much specification? In the conversations you mentioned with the PO, developers could definitely create implementation tasks for themselves to deliver the "right thing".
My only worry would be when QA comes into the mix. Would they get enough out of the slimmed down stories to test effectively?
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.
Hi Igor. Good article! As an agile coach and Scrum Master, I almost agree to everything you wrote.
There's one thing I maybe see a little bit differently: user stories are originally intended as a "promise for conversation", as Alistair Cockburn has described it. They are not primarily used as specification.
So my ideal scenario is: the PO meets with the devs and discusses story ideas. They write down "just enough" so that everybody has the same understanding. "Just enough" is adjusted in the retrospective.
Hey! Thanks for the props 😊
That's interesting... So in that model, stories are slim and describe the general ask without too much specification? In the conversations you mentioned with the PO, developers could definitely create implementation tasks for themselves to deliver the "right thing".
My only worry would be when QA comes into the mix. Would they get enough out of the slimmed down stories to test effectively?
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 🙂