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:
- It can be a description of a feature.
- It can be a vertical slice of demonstrable functionality.
- It can be a placeholder for discussions with stakeholders about what needs to be implemented, or what a successful story implementation might look like.
- It can be a placeholder for technical discussions about how to implement a feature.
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.