3 ms·
Uh, for me sad part is when I try to make those people write stories in more detail like "what should happen if data fails to load", "what should be default sta
by ozim 11y ago
Uh, for me sad part is when I try to make those people write stories in more detail like "what should happen if data fails to load", "what should be default state", "Ok we have adding for an element, how we handle deletes". I got question "So should we go back to the waterfall?". Because we are so agile that not everything should be specified up front. But they do not get the scope, single story does not fall into waterfall...
- lostcolony 11y agoYeah, that sounds like a broken process. The story is the last possible moment of decision making before the developers go and develop something. Obviously it may need further refinement at a later date once you have learned something. But, by definition, you now know -everything that can be known before development starts-, because development is about to start. As such, anything, -anything- that remains unspecified, is, again, by definition, undefined. It may be worth explaining that if failure conditions remain undefined, then you will ignore them for convenience, because whatever you decide to do will almost assuredly be wrong. If the product owners want -any- say in what it does in the event of something going wrong, and don't want it to be a surprise, and require even more work, then now is the time to say something.