I'm working on an update of an existing medical software and I defined user stories together with some end users. If you're not familiar with medical environments: A doctor usually has multiple patients. Each patient has multiple cases (broken leg, skin disease, etc). In medical terms, a case will be closed once the patient was treated. This might happen after a few days (illness) or sometimes weeks or months (e.g. if physiotherapy is involved). However, in most medical software, cases have to be closed after a predefined timespan (couple of days or after a month) for the billing, because most health insurances will only pay for closed cases.
The doctors in most hospitals and clinics here use a standardized form when they have a consultation with their patients, the APE Form (Annual Physical Exam).
The UI of the software is not very user friendly, therefore a big part of my work will be to improve the user experience. The UI of the cases of the current version looks very different to the APE Form and specially new doctors have troubles with the UI because of that. Therefore we want to change the UI, that it looks more like an APE Form.
Now I've got the following 2 user stories and it seems that the 2nd user story is a child of the 1st one.
1st user story:
As a doctor, I expect a case in the software to look like the APE Form.
2nd user story:
As a doctor, I want to see the whole medical history in a patient case, to get a quick overview of the medical data (see attachment)
Is this correct? In all projects I've worked before, user stories were always either completly independent (means no parent) or the child of a feature. That's why I'm not sure if a user story can have another user story as a child.
Best Answer
I think you're over-thinking this.
What is the ultimate aim? Are you trying to deliver a quality outcome for the business, or are you trying to follow a methodology to the letter?
Now, in a sane world, the answer would be obvious and I would simply advocate that you specify your requirements in whatever way describes the problem clearly and unambiguously. So, sub-stories are fine. When I was a developer, I would have had no problem understanding your intent and delivering it.
In a less sane world, you can have passive-aggressive developers looking for loopholes to exploit so the defect tracking system shows more defects attributable to the analysis than the developers; or external vendors who make more money out of artfully delivering exactly what you specify despite it not being what you want and then charging a fortune to close the gap. If you live in this world, you need to be absolutely sure that your specification follows whatever methodology the development team are expecting to receive.
So the absolute right answer depends on two things, your political context and the agreed methodology. If there is any doubt, spend half a day doing a few nested user stories and present them to the development team for review. They should be able to let you know where you stand in less than half an hour.