Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Are User Stories Really The Best Way for Software Development?

Hi All,

Our company has been on the same discussion for months and havent been able to come to a conclusion. Would appreciate some inputs!

In Agile and DevOps, the popular recommendation in Software Development Ticket Structures is to use the following:

  • EPIC (Name of Project)
    • STORY (End user desired outcome)
      • SUBTASKS (Department involved and the task to be done)

However, in our company, despite the Agile training we have went through, we are unsure if this structure would work well for our SDLC.

The reason being is that we are unsure if our Project Managers are able to translate complex customer requirements into User Stories.

We develop products for the finance industry. Requirements are heavily complex relating endless scenarios and business formulas to implement. The nature of it makes it hard to put into user stories.

One of the current discussions in the company is to follow this structure instead

  • EPIC (Name of Project)
    • STORY (Name of Department)
      • SUBTASK (Task which Department needs to carry out)

The end result would look something like this:

  • EPIC : Resolve Pentest Issues
    • STORY : Front End Dev Team
      • SUBTASK : Resolve Pentest 1
      • SUBTASK : Resolve Pentest 2
      • SUBTASK : Resolve Pentest 3
    •  STORY : Back End Dev Team
      • SUBTASK : Resolve Pentest 1
      • SUBTASK : Resolve Pentest 2
      • SUBTASK : Resolve Pentest 3

But after months of discussion, we cant seem to find a clear answer as to which structure fits our use case the best.

The conventional 'User Story' based structure is in consideration because its the recommended practice for SDLC. However, the 'Product/Department' based structure just seems easier to track in general. It looks better on our roadmaps too.

Hope you guys could route us to your product/practice advocates to shed some light in this area. We really cant decide.


John Funk Community Leader Aug 02, 2022

Hi Bryan,

My quick answer is No - Kanban is.  :-)

Like Robert Wen_ReleaseTEAM_ likes this

Yep, with Kanban, you don't need any structure, it's just a big pile of issues, all at the same level, so all your problems go away!

I think there's a bit of a problem with your first definition.  It is not what Agile or Devops recommend.  They actually recommend the second option. 

I could write a short essay on the difference, but the short version is that Agile and DevOps expect a story to be an actionable item that one single team can complete.  

In your first definition, you've got the layers shifted down too low, it should be

  • Epic (End user desired outcome, which may need work from many teams)
    • Story (Team that will do the  work and the task to be done)
      • Sub-task (fragments of a story that the team decide to split up for whatever reason)

I would take another look at how you want to work, and design your structure upwards, starting with the Agile definition of Story (one distinct piece of work for one team)

Like # people like this


Log in or Sign up to comment

Atlassian Community Events