5

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.

1

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.

| improve this answer | |
  • Yes you are right, What I can do is - I can have a short document with Story Name and its mapping with affected/new classes ,methods,database tables,procedures instead of class diagram and sequence diagram. And a Technical short description. And above each class ,methods,procedure code - I will ask the developer to mention the StoryNumber in the comments. – Roop Oct 28 '15 at 15:24
  • @Roop: IME, it makes usually more sense to refer to the story that relates to a change in the check-in comment than in a comment in the code. At first a class might be related to a single story, but after a year or so, most stories will probably cause small changes to several classes. – Bart van Ingen Schenau Oct 30 '15 at 20:43
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.