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:
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
The end result would look something like this:
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.
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
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)