Should we write technical stories against business stories where technical stories will have class diagrams or sequence diagrams, or where technical items will be broken down into design tasks extracted from business stories?
This question is broken out from the original question as asked by Mark Phillips and CodeGnome.
You can write them, there is nothing against it, however these documentations tend to take a lot of time write, and after one or two weeks they are obsolete, even though architects claim that they are going to be useful later. This is rarely true, maybe in health care services where technical documentation is mandatory per FDA.
I'd rather do technical discussions and one pagers than class diagrams. They fit better into the agile mindset: they involve the whole team - collaboration -, team discusses decisions together, and they are effective and efficient.
Should we write technical stories against business stories where technical stories will have class diagrams or sequence diagrams, or where technical items will be broken down into design tasks extracted from business stories?
No. A user story is not a requirements document. A story should follow INVEST criteria, but can be many things:
In short, the user story provides context and guidelines for what should be implemented, but the specific details of how to implement a feature is left to the development team. As a result, detailed technical requirements should not be embedded in the story itself.
In general, the right place to decompose a story into implementation-level details is in the second half of Sprint Planning when converting stories to tasks on the Sprint Backlog. Not all teams do this, but if you're going to do it at all, this is generally where it should be done.
