I'm looking for references that might help explain what I've seen in software engineering regarding processes for developing in the front-end vs the back-end. They are both difficult, but I tend to feel that the front-end is easier to write stories for, and to possibly estimate the amount of effort (time).

There might be a number of reasons for this: sand-boxed tech (js, css, html), the visual aspect lends it self to themes/grouping/modularization, etc, Users interact with the UI and process artifacts tend to be called "User" stories which implies that the process wants to capture a goal that entirely is visible and improves the quality of life through the front-end.

As for the back end in contrast: there aren't typical UIs, and the data varies greatly to provide details for operations (logs, metrics, deployments, etc). Yes data for the front-end can be varied as well. The User is almost always either a dev or support, but these people rarely sign-off or "accept" these stories, and they are rarely the stake-holders for the implementation, much less control the budget for the implementation. Also, there doesn't seem to be any notion or complete set of back-end tools like js,css,html are for the front-end, and therefor also no compatibility layer.

With this in mind I'm hoping to understand if it makes sense to use the same software development process for both the front-end and the back-end? Yes there are users of either system and breakdown of work needs to occur, but the biggest difference hidden in the above descriptions is that the front-end Stories are after some visual design, while the design in the back-end is coupled with task breakdown for back-end.

Perhaps, as is generally the case, this is a bias from my own experience? Other approaches are sure to exist, especially based on project size and scope, etc. I'm simply looking for some more insight. How should process be different for front-end vs back-end?

  • 2
    You're not asking the right question. Absent a more specific definition of "software development process," you've already answered your own question. Of course the techniques are going to differ, because the nature of the technical problems differ. You've hinted at the actual question ("How do I get a budget for things the stakeholder cannot see"), but that's not the question you asked. Jun 16 '20 at 15:19
  • @RobertHarvey "How do I get a budget for things the stakeholder cannot see" is not the question I'm asking. Having a budget, the item prioritized and in the pipeline and now working on it, assumes I have a budget, else I wouldn't be able to work on it at all.
    – lucidquiet
    Jun 16 '20 at 16:59
  • I do agree that I've likely answered my own question: they should vary in process based on the nature of the technical problem. However, was hoping for a when and why. But that's a little too much. RUP for governments vs Spiral vs Rapid isn't really where I was headed.
    – lucidquiet
    Jun 16 '20 at 17:01

The User is almost always either a dev [...], but these people rarely sign-off or "accept" these stories

You've hit a personal hot button here: developers should never be the actor in a user story (unless you're developing a framework like Tensorflow or something). You develop a product for the stakeholders, not for developers. I far too often see stories like "As a developer, I want the code to have unit tests" - but this is not a user story, because user stories have the form "As an X, I want Y so that Z". In my experience, once you write "Z" you're forced to think about actually why you're doing the work and who it's for.

"Support" is a mixed case here - I've seen cases which aren't really stories ("As a support engineer, I want the system to log to CloudWatch" - that's an implementation detail which the support engineer actually doesn't care about) but other things which are actually user stories - for example, something like "As a support engineer, I want to be able to filter logs by customer ID so that I can more easily find the cause of a customer's error". However, for that second example note that it's neither a front-end nor a back-end story - it's a story for the product.

How should process be different for front-end vs back-end?

It shouldn't. Or perhaps put another way - you shouldn't divide your process in this way. Write your stories so they reflect a product need.


We use SAFe at my workplace, which has a separate category called enablers to capture work that isn't directly user-visible. We also tried to organize into teams that could be given a feature and do both the front and back ends within the team. I say "tried" because over time the specializations just sort of reformed.

That being said, I'm a firm believer that if your process isn't somewhat different for every team, you're probably not really doing agile. Not only should a front end team work somewhat differently from a back end team, but back end teams should work at least slightly differently from each other.

If the user story format isn't helpful for your circumstance, you should talk about in a retrospective and try something new. If you feel you aren't getting the right kind of feedback from your actual stakeholders, you should talk about it in a retrospective and try something new. If you feel you don't understand how your work is eventually used by the end user, you should talk about it in a retrospective and try something new.

Frameworks like scrum are there to give you a jumping off point. They aren't rules to be religiously followed no matter how well they work for you or not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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