Awesome thought. I agree with this post except on the point of everyone do it this way. Best practices are a myth and if something is working and the team and its stakeholders all understand and get value out of their abstraction, definition and understanding of a user story, no one from outside can move them to change if they don't feel the pain you are solving. I like this as another tool in the bag, but rules are for breaking and are always open to interpretation and improvement.
Fred is a software jack of all trades, having worked over the last 24 years at every stage of the SDLC and has authored [two books](https://www.amazon.co.uk/Fred-Heath/e/B08F3Q1H1M).
Hi Charles. Yes indeed, I would never prescribe this (or anything else) as a panacea. It's just a good way I found of modelling and bridging Requirements to Specifications while avoiding getting lost in the whole 'user story' kerfufle.
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.
Awesome thought. I agree with this post except on the point of everyone do it this way. Best practices are a myth and if something is working and the team and its stakeholders all understand and get value out of their abstraction, definition and understanding of a user story, no one from outside can move them to change if they don't feel the pain you are solving. I like this as another tool in the bag, but rules are for breaking and are always open to interpretation and improvement.
Hi Charles. Yes indeed, I would never prescribe this (or anything else) as a panacea. It's just a good way I found of modelling and bridging Requirements to Specifications while avoiding getting lost in the whole 'user story' kerfufle.