I would say that beyond the admonition that user stories be small enough to finish in a sprint, it’s really a matter of what works best for the team, and tools should lean toward flexibility rather than arbitrary restrictions.

For most teams in most circumstances, putting an epic under a task makes no sense, but I can think of some use cases for the tool allowing it. For example, we often have a story where the output of that story is a set of future stories, like to investigate a feature and break it down to the user story level. Being able to attach those stories to the investigation story would be extremely convenient, then split them off before you close it.

For another example, maybe something turns out to be a lot more difficult than you first expected, and you need a convenient place to rescope the work. Just because you’ve never needed a feature doesn’t mean it’s useless.

A chainsaw will allow you to cut your leg off, that doesn’t mean you should do it.

That being said, if there is reason the team is doing it (e.g. It helps to tie it back to a master road map or similar), then by all means continue. If you are just doing it because the tool allows you too, then it beings to feel a lot like muda and a good topic for discussion at the next iteration retrospective.

Epic is not a special artifact. It is a user story (or product backlog item) violating some basic characteristics of common user stories:

• It is usually a big story with a lot of hidden details
• It usually contains a lot of uncertainty because of hidden details
• It is usually very hard to estimate such story (sometimes even impossible) again because of size and uncertainty
• It is usually not possible to fit a discussion about story details or acceptance criteria into some used time box because there is simply too many of them (one Epic story can take more time for discussion then whole planning meeting – once you have suspicion that this is going to happen you should immediately exclude such story from planning)
• Even if your estimation counts with uncertainty you very often ends with the estimate which doesn’t fit into iteration length

But even with these characteristics it is still a user story and it belongs to product backlog. The story can become an epic by two ways:

• Product owner declares it as epic – It is usually some high level feature noted for future investigation or discussion.
• Team declares it as epic – It means that team doesn’t understand the story because it is too high level for estimation. The story must be divided before team can proceed with this story.

What you may find the most important is that in both scenarios the epic user story is work for product owner – not for the team. The product owner must take the epic and split it into more specific stories resolving all bad characteristics of the big one – it may be even iterative process (there may be even more high level backlog item called Theme). Product owner is responsible for maintaining product backlog – no one else.

In my current team there is a practice of putting Epics under User
Stories and sometimes even User Stories or Epics under Tasks!

You can sometimes consider user story as a task. It depends on granularity of tasks you want to achieve. If you for example use 1/2, 1 and 2 days tasks you can easily find that some user stories fit into such metric. But epics should obviously not fit even to 5 days tasks (unless you have one week iterations).

There are three explanations to your core problem:

• Those user stories are not epics – this may be the simplest explanation. If the team handles those stories without problems, with correct involvement of product owner, with all acceptance criteria passed and within single iteration they are most probably not epics. They could be in the past but as the team builds application the knowledge about the domain grows as well as already implemented code. The real complexity of these user stories may be already different as well as the estimation. In such case it is time to schedule a new estimation session and re-estimate all previously estimated stories (team should still use the same size for story point as in the initial estimation!)
• Those user stories are not epics but the team insists they are – this is skill or confidence problem. One reason may be that the team is not skilled enough (with a methodology or tool they have to use) and they are not confident with their estimates so they may put some spare time into some stories. If this is a problem of overestimating you must find a reason why is it happening but the global overestimating in general should be eliminated by correctly using velocity from previous iterations for next iteration planning.
• Those user stories are epics but teams somehow magically manages to complete them. That should be a big warning. If the story was considered big without detailed information you may end with incomplete feature – even worse with feature where the team decided how to quickly implement it instead of discussing it with product owner – the whole implementation can be waste because the feature was not understood correctly. This is mainly responsibility of product owner to stop this. If you have weak product owner you must make your best to stop it yourselves because this may end by a big failure of the project.

if it is not a good practice then the project management tool would
not have allowed doing so!

So you must show them that current practice is wrong. How long is a task containing the whole story or even epic? What team members say about work they did yesterday on daily meetings? If they says that they did something it means that they completed some task they were lazy to create. If they don’t say that they did something for two days how do you know that they are not stuck and don’t need help? How do you know that they are actually doing something?

And even worse: How do you track an iteration progress? Do you have a sprint burn down chart? What does it show? If you have epic user story as a task how long does it take to complete? I like to use two sprint burn down charts: one for tasks and second for stories. The first one is more internal progress tracking tool whereas the second one is the real iteration progress (at the end of the sprint only completed stories matters) but in both cases you can change the chart only if the task or story is complete – you never make changes just because you worked on a story two days but five still remain to complete it. You will extract 7 days only when the story is done because only in such case you measure your progress of work completion.

Extracting days or hours based on incomplete work is like tracking how many mandays your team spent on the project since iteration started. That has nothing to do with progress tracking – you don’t need to know that team worked on features 122,5 hours this week. You need to know how was that 122,5 hours used to complete work. If you don’t see how tasks or stories where completed during those 122,5 hours you are doing it wrong – in the worst case you can end with 122,5 hours spent and none completed task or story. Even if everything goes right you may end in situation where you have 10 stories planned for an iteration and at the end of the iteration you need 10 more hours to complete planned stories – 1 hour for each. How do you think my burn down chart would look like in such case? Yes, horizontal line since a day one to the end of the iteration = no work done because that is exactly result of such sprint.

IBM Rational Team Concert, for one does not prevent such practice.

I have never used that product so my judgement may not relate to that concrete product but I learned one thing about enterprise software (IBM makes enterprise software). Most (but not all) of enterprise software products are created to amaze people responsible for purchasing enterprise products, not to amaze people who will have to use those products. It is important to have tool solving some enterprise problem in “enterprise” way.

The greatest agile management tools come from smaller agile companies where agile is really used and it is not bent to fit enterprise bureaucracy. I would not be surprised if agile management tools provided by enterprises had been created by teams not using agile and even people who never used agile before. Agile is a trend and every big company providing enterprise software must have its own tool – at all costs.

If by “under” you mean a parent-child or composite-component relationship, this definitely makes no sense. Epics are big unrefined chunks of specification which you break down into user stories over time, not the other way around. Ditto for tasks and user stories.

Tools like TFS allow other types of relationships between work items (predecessor, related, concerned by, etc.) though.

So the answer to your question basically depends on whether your coworkers got the concept of epic completely wrong and want to reflect that in the tool, or just want some kind of weak link between epic and user story, which may be legitimate.