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.


4 Answers 4


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.

  • You gave me exactly the answer i needed to hear. Right now, I'm building up the development team in our company. In the past, we had external companies doing the software development for us, but this is changing now. This means I can set the standards on methodologies right now and therefore also set the grade of sanity. My goal is to use this project to define development guidelines, including the requirements engineering, testing, etc. Therefore I can specify what's right.
    – Davatar
    Commented Nov 18, 2016 at 6:39
  • Glad to hear it. With an in-house team you can develop sane guidelines that the analysts and developers s can agree on, or at least tolerate :). Using agile and in-house you're no more than one iteration away from fixing the worst misunderstanding and even that can be a positive learning experience for the team to improve communication. Good luck but it sounds like you're on the right track.
    – mcottle
    Commented Nov 18, 2016 at 6:44
  • @mcottle Asking if the ultimate aim is a quality outcome or following a methodology to the letter sets up a false dilemma. It is in the act of following a methodology that we strive for a quality outcome. Besides that, most of the methodologies do not have a "to the letter" approach but prescribe ways they can be contextualized. Commented Dec 2, 2016 at 3:35
  • @ScottShipp that was where I was leading OP - to the point of tailoring the process to suit the organisational situation. I didn't go all that way at first because there are some organisations that DO follow a process "to the letter" whether it makes sense or not (a "Cargo Cult" style organisational antipattern) and I was just ensuring he had the leeway to tailor before I advocated that.
    – mcottle
    Commented Dec 2, 2016 at 4:15

Okay, so here's the thing about Agile that none of the folks selling two day certificates will tell you:

What may work for my team may not work for yours. The whole point of Agile Software Development is to, through experimentation, figure out what works for your team.

So, perform an experiment as inexpensively as possible. Do one story this way. When it's done, talk to your team about what was good about it, what was bad about it, and if the experiment should continue or not.

I personally don't see a reason why you can't have a sub-story, but it might cause you a headache because the stories may not be independent enough to deliver separately. With that in mind, go try it, then come back and share your results as an answer here.


Your scenario doesn't sound like a parent/child relationship, but a simple dependency. The second story can't be completed until the first one is completed. In fact, as written it's not even dependent. You can certainly complete a story of "see the whole medical history" without having the APE form (unless the APE form is "the whole medical history").

Perhaps a better way to look at this is to reverse the relationship. It seems to me you have one epic, which can be expressed like this:

Epic: 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)

You would then break that epic down in to multiple independent stories:

  • Story: As a doctor, I need a tool that lets me view each piece of the medical history
  • Story: As a doctor, I want the medical history viewer to include X
  • Story: As a doctor, I want the medical history viewer to include Y
  • Story: As a doctor, I want the medical history viewer to include the APE form
  • Story: ...

As part of release and sprint planning, you can order the stories based on the dependencies. Maybe you can write the viewer without having anything to view, and then you can add things to the viewer. Or, you can write the individual pieces of the history before tackling the viewer. It's your team, let them decide the best way to handle the dependencies.

That happens all the time in agile. In fact, one could argue this is the normal case. Stories can't exist in a vacuum. You can't write a story to print a report until you've completed a story that creates a report. You can't create a report until you've build a database to hold a report. And so on.

So, think about the big picture first "I need to see all of the medical history", and then break that down into bite sized pieces. "I need the medical history to include the APE", and so on. It's perfectly natural for these stories to have dependencies on each other, and you can't change that fact. Part of the goal of writing the stories is to make those dependencies visible.


This is a non-functional requirement. The second user story is expressing a functional requirement. They are two separate requirements even if in practice they are related. For a clearer example:

  • (functional) User can make request for X.
  • (non-functional) System can handle 1,000 requests per minute.

You can express this a user story if that is how you want to do things (first google result for advice on how to do this: https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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