Are User Stories Really The Best Way for Software Development?

[Bryan Tiang]

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]

Hi Bryan,

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

[Nic Brough -Adaptavist-]

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!

[Nic Brough -Adaptavist-]

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)