Let's consider the following and somewhat prototypical user story in one's backlog:

As a user I want to be able to login to the application so that I can do all sorts of private stuff

Now, this is obviously intrinsically composed of 2 major parts (as do most of the user stories out there):

  • UI (frontend)
  • Some server side service (backend + DB)

My take on this is that it provides end user's value as it is (as a whole and with no differentiation between UI and backend processing) and that it makes no sense to decompose into smaller user stories.

What it does make sense though is breaking it down, during sprint's planning into tasks that can be developed by different devs. But I suppose that's a different matter that only helps the team from the operational point of view and is somehow irrelevant for stakeholders (in the end, during the review, they will get a login facility and be all happy about it).

I just wanted to know what you think about it and if decomposition into a UI story and a server side story would make any sense and somehow helps the process.



As a rule of thumb (there are always edge cases and exceptions), user stories should represent a potentially-shippable unit of work related to the Sprint Goal. Unless you can ship the front end and back end capabilities independently, it doesn't make sense to split a story based on who will be doing the work.

Split Tasks on "What," Not "Who"

In Scrum, it doesn't make sense to split anything from a Product or Sprint Backlog based on who will do the work as opposed to what the work is. While there's an arguable point of view that fully-decomposed tasks can be deliberately aligned with individuals or target individual skills, tasks should really still represent increments of work in a user story's development rather than individual assignments, and as such the tasks should belong to the Development Team as a whole. That definitely argues against decomposing user stories into personal tasks, but that is something I'd leave to the Development Team to hash out as the workflow evolves.


As a user,
I want to be able to login
so I can access the web site using my saved preferences.

This story has implicit front end, back end, and persistence requirements. From the user's perspective, delivering sub-components of the feature won't really advance the flag, so splitting this into model, view, and controller stories doesn't really make a lot of sense. Of course, there will be model, view, and controller tasks required to get this story done, but whether or not you really need to split those intertwined tasks down along those lines depends more on how the Development Team works together than anything else.

If the team members are very I-shaped, rather than T-shaped, you could conceivably split the tasks that fine, but then you're faced with an integration problem when everyone brings their tiny piece of work back together to meet the Definition of Done for the story. As an experienced agilist, I'd argue that the better thing to do is to let the Development Team self-organize around the story. Perhaps the Javascript, PostgreSQL, Ruby, and Cucumber developers will all mob program this feature together. Then again, maybe they'll split the work into tasks, parcel them out between themselves, and then come back together to integrate the work. Let the Development Team work it out for themselves, and then evaluate the outcomes of the process during Sprint Retrospectives.

To Decompose or Not

Scrum doesn't take a position on how to divide tasks, or how granular they need to be. It also doesn't really require decomposition of user stories into tasks on the Sprint Backlog, although doing so can be useful as an information radiator for complex or long-running stories.

While Scrum doesn't take a position, the principles behind the Agile Manifesto do. The 10th principle is to maximize work not done. That means formal, upfront decomposition (which is also work!) for its own sake is often an anti-pattern. The Development Team owns the Sprint Backlog, and should therefore decompose user stories just enough to coordinate and communicate within the team.

If decomposition is helpful, then do it; if it creates more overhead than basic face-to-face collaboration without a tangible benefit, then don't do it. It's really that simple!


I find that it is usually the case that a "user story" must be decomposed into a different set of tasks which actually drives the fulfillment of that "story." Furthermore, the exigencies of the underlying system may demand that those tasks be fulfilled in a different sequence, and even that a particular "story" must for a time -- maybe even a long time -- remain "partially unfulfilled." The architecture of the underlying system is what must drive the actual workflow. "Front-end / Back-end" is only the tip of that iceberg.

"User stories" are a convenient way to drive the work process in a way that is easily understandable to users and other outside non-technical stakeholders, but they are not, usually (IMHO) what actually drives the work breakdown structure.

In my experience, there is first a discovery process to determine what parts of the system will be impacted by "a story." Then, there is a design process to select what the actual breakdown needs to be. There then might be an ordering to determine the proper (and, least impactful) way to carry out the work. As the work proceeds (acting off of this breakdown, not mere "stories"), it can be mapped to "story terms."

IMHO: The Scrum Guide is an excellent guide, but it is also a simplification. Some projects are of such a nature that they can follow it quite closely. But, many projects must adapt it. "And, IMHO, that's to be expected."

  • In my experience, this is true. – Eric Hartford Apr 26 at 15:30

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.