I planned to slice in backend development into to the user stories vertically. But a backend guy on our team started to complain that this makes their work invisible.

My answer was that

  • at the sprint planning and review meetings we discuss backend tasks in front of stakeholders so it makes it visible, and

  • maintaining a high quality during the project will result a slower startin pace than other teams, but we will have a stable velocity during the project. And velocity is highly visible to stakeholders.

He still insist having stories like: "As a developer I need to have a domain layer so I can encapsulate business logic."

How can I solve the issue before it pollutes the team?

The root of the issue is that our management systematically consider backend work as invisible and call backed devs miners, or other pejorative terms.

  • 7
    I wouln't have the backend stories, they make no sense.. However, I wouldn't like to have that kind of managers.. I thought the backend devs were the rockstars some time ago
    – margabit
    Commented Jul 3, 2013 at 8:21
  • 2
    Making separate back-end stories implies that the back-end work can be prioritized separately from the front-end. This has the risk that the priorities get assigned such that the back-end work gets relegated to the bottom of the backlog until it gets re-incorporated in the front-end stories. For the problem with the lack of appreciation from management, I recommend you ask about that over at Workplace.SE. Commented Jul 3, 2013 at 8:41
  • My fantasy solution involves occasional slapping of all parties. slap Stop whining. slap Stop ignoring the critically important role that data and business logic contributes to the success of the business that pays our rent. slap Stop eating other people's lunches. It's not your mom's refrigerator. Commented Jul 4, 2013 at 2:20
  • 1
    slice the topics vertical, then slice the resulting stories into horizontal tasks.
    – jwenting
    Commented Jul 4, 2013 at 5:49

4 Answers 4


There are a few things wrong with the situation described, the obvious problem being the lack of respect given to the back-end developers. As this question is tagged agile I am going to push back on other answers suggesting this is only a social problem. There are several bad smells and possible anti-patterns in your story, none of which have to do with ignorant management or even how you slice the stories.

The fact that a group of individuals on the team feel slighted for not getting glory from work completed smacks of several possible problems.

  • There should not be people who only do back-end development. A common Agile approach is to have cross-functional teams made up of generalizing specialists who practice shared code ownership. Individuals should not be focused exclusively on back-end or front-end development, though they will certainly better more experienced or better at some things than others.
  • Architecture doesn't earn value. From a user's perspective -- the only perspective that really matters -- it does not matter if you have layers or domain languages or even if the solution is programmed. The only thing that matter is whether you created value for the users. The proposed "story" from the back-end developer is a nonsense requirement -- it is a summary of design decisions that, from the perspective of a user/customer do nothing to achieve the functionality desired. In other words, any given user story might be achieved by any number of different architecture designs. It's possible that a user story might be completed with no modification to the back-end at all. This does not make it an invalid story.
  • Thinking systemically is still critical. While architecture may not earn value it is still critical to success. The back-end developer has some valid concerns. You should be thinking about how you will build the system. You should be writing those decisions down. The whole system is important even though only the front-end features are the things that will get all the glory.

My recommendation is to treat architecture as a first class citizen -- but do it the right way. Perform a quality attributes workshop with stakeholders. Involve key stakeholders in architecture reviews, or at least summarize essential design decisions at important milestones. Draw the architecture on big paper and make it visible so the entire team can see it.

Require that everyone develop everywhere in the system (front-end and back-end), pair program if you need to so this can happen effectively. Continue to create user-focused user stories. But also identify key quality attribute scenarios that show why the system is designed the way it is and drives decision making regarding "back-end" design. Elevate the architecture design so that it is not invisible anymore.

  • 1
    Thank you for an actionable answer! I would like to clear up a bit of an understanding caused by my wrong wording. He is not just a "backend dev" actually he working all over the stack even in firmware. His pain point is backend architecture not getting proper recognition. And while architecture does not earn value by itself a sloppy architecture can break systems or at least it can make them very expensive to maintain. My plan was to facilitate more talks about the architecture during review and planning meetings, and quality workshop looks like a great tool too!
    – Szili
    Commented Jul 15, 2013 at 12:50
  • FWIW, it is not always practical to have a developer work the full stack. One requirement in my current company might involve CICS development on an IBM mainframe, MQ, Java in Mule ESB, Datapower, and then finally a rich web UI with jquery and other templates. Another user story might involve CORBA talking VMS COBOL, and another backend is written in Gupta. Commented Jun 12, 2014 at 21:35
  • @AlanShutko - exactly. "One person's front end is another person's back end" right? This is one of the reasons why I dislike slang like "back end" and "front end" especially when talking about multiple components in a system. Your point is extremely important! Even "full stack" is a relative term that can mean different things in different parts of a system!
    – Michael
    Commented Jun 13, 2014 at 13:34

This seems to be a social problem, so it will need a social solution.

If (as I understand you) backend developers feel ignored and slighted, and feel that their work is not valued enough, then there is little that the development process can do to change this.

If I understand correctly, I looks like the devs feel that they should at least have their "own" user stories, so they can point to them and say "This is what we did, just us backend guys/gals". However, having stories sliced "horizontally" like this is a bad idea, and I agree with you to slice them vertically.

The best solution is probably to have a quiet talk with the developer(s) in question (individually or as a group), and address the underlying problem, which seems to be one of respect. At some point, this will probably need to escalate to management.

  • Thank you for the answers. The problem is a social one indeed. Today we talked over yesterday's argument, and the developer in question told me it was more about years of systematic disrespect of his back end work than about his view on our current project and his understanding of the scrum process. We agreed on moving forward with vertically sliced stories.
    – Szili
    Commented Jul 3, 2013 at 11:39
  • 1
    @Szili: Is has backend work so bad that it doesn't deserve any respect, or is he just ticked off that he's not getting recognized?
    – Blrfl
    Commented Jul 3, 2013 at 15:59
  • His backend work is excellent. Proper recognition and even management bullying is the problem.
    – Szili
    Commented Jul 15, 2013 at 12:34

The root of the issue is that our management systematically consider backend work as invisible and call backed devs miners, or other pejorative terms.

Indeed this is the problem. It's obvious you won't solve it with stories!

In general, one of the feature of agile development is transparency. This also means that it makes your organizational problems more manifest.

The standard agile solution to this problem is to adopt a more "vertical" or "full-stack" approach to development, where your backend devs take stories from top to bottom instead of simply working in their comfort zone of the back end tier, and frontend devs likewise stretch towards the backend(*).

In other words: make everybody produce value for your end users.

(*) Note: not all stories need to have a front-end component or a back-end component. UI elements can be reshuffled without additional back-end work, and performance is a feature.

  • 3
    Sounds like you have zero understanding of backend development. See how little value a good backend guy serves when the front end guys do all the data modeling and logic implementation in the front end then wait six months. Most good engineering isn't good about producing immediate value, it's about producing long term dividends. Your approach applied to bridge building would have every bridge made only to stand for a week and it wouldn't have a blueprint or architect because those are not immediate value. Commented Jul 3, 2013 at 13:03
  • 1
    No @JimmyHoffa I am quite familiar with back-end development. My answer is pretty much textbook agile. As you might notice, I don't advocate having front-end people only. If you don't like agile, don't use it, but I am simply describing how a methodology works, so do not assume stuff about me, or whatever else.
    – Sklivvz
    Commented Jul 3, 2013 at 13:09
  • 2
    The part where it veers off track is where you're saying the back end guys aren't producing value and should just be doing front-end work, if that's not your intent in this answer, you should really reword it to be more clear what you do mean here. Commented Jul 3, 2013 at 14:33
  • 1
    @JimmyHoffa But they are not producing any value, to the end user. If it was a team of only back end developers then the users would be the front end developers. In that case your reasoning would make sense, but it doesn't seem to be the case.
    – Sklivvz
    Commented Jul 3, 2013 at 14:36
  • 1
    If in your world value is only produced by the creation of a user interactable product, and back end developers are unnecessary to that then in your world apparently architects and project managers, business analysts, HR and everyone else is irrelevant as well. In my world value is produced by the quality of a systems design and implementation such that future feature development doesn't involve wandering through the spider web of an access database because only user-interactable-product was valued... Quality implementation is value. Maybe not immediately, but in the long run. Commented Jul 3, 2013 at 14:44

Your problems are:

  • You have layers of management up in your business where they serve no purpose. Scrum, agile, I don't care. Management and development should be isolated with business concerns handled by a product manager who has a !@#$ing clue about technology. Maybe it worked for Steve Jobs but I have never been in a situation where non-tech-adept managers being close to dev was a healthy thing or ultimately served to produce the best quality product a team could have made.

  • You have devs who are more worried about appearances than they are solving problems. That is either a very serious culture problem (seems likely given this whole "miner" phenomenon) and/or you have a dev quality issue, which also wouldn't shock me given the lack of confidence.

Get the people who don't need to be there out of planning and standup. Anybody who has notions about back-end being any less important than front-end is somebody who doesn't need to be there and is in fact hampering the process by being there.

Ditch stories. Yes, I'm serious. If they're causing these kinds of issues, toss 'em out the airlock. At my current job we just stick to the "done" criteria for a given task, which typically stays more focused on the app than the user of it which may offend those who think agile (which has been changing constantly for 20ish years) won't work if you don't follow it to the letter, but really if we're pros, we don't need anything that's causing problems for us. Crumple 'em up, toss 'em over your shoulder.

And you might want to remind that dev that the people they really need to worry about are their immediate peers, not the folks who are too clueless to be at sprint planning.

  • Good advice. Keep in mind that there is nothing in the agile manifesto about "user stories" and they are just a popular practice that came about with specific processes. You can be just as agile with user stories as you can without..
    – Michael
    Commented Jul 9, 2013 at 4:02
  • This is true. I'm not sure the agile manifesto would be considered enough to be "doing it right" by a lot of the standards of the whole training industry that's been built up around it, but as always the ideas and which ones make sense to you and your team should take precedence over the affectations, IMO. Also you'll get as many answers from that front about how to "do agile" correctly as you would asking college students what the rules of dating are. There's no substitute for critical thinking. Commented Jul 9, 2013 at 13:22
  • I wouldn't ditch user stories. Actually I'm working hard to introduce them as we have a tradition of disregarding endusers. The Steve Jobs analogy is very apt as our CEO is a brilliant technical guy who bootstrapped multi-million company. The one thing he failed at is building a managerial layer, so he remained very hands on with the work done. This gave way for the emergence of star culture which results in worrying about appearances. To summ it up: we have a cultural problem. But considering it as given I need the tools like the ones in the answer to make the baby steps needed.
    – Szili
    Commented Jul 15, 2013 at 13:05
  • Either way, I'd recommend an experienced anal-retentive UI dev if you're having UX problems. There's no substitute barring some awesome generalists that few would ever want to pay a full team of. Commented Jul 15, 2013 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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