I've heard many times that tasks are basically subsets of user stories and they are derived from User Stories, so on the scale of amount of work that is needed to finish them, a Task is always smaller than a User Story.
I'm curious though if there could be any cases, when a Task is not derived from a User Story, thus can contain a larger amount of work than some User Stories on the Product Backlog?
Is Task always decomposed from User Story?
No.
Tasks are often split from a user story, but that does not mean that a task can only exist as part of user stories and thus they always have a smaller size. Tasks can exist by themselves.
You tagged the question Scrum. User stories are not a Scrum specific thing. Your Product Backlog isn't composed of user stories only. You can have epics, stories, bugs, tasks, spikes, or whatever your product needs. Scrum generically calls all of these Product Backlog Items.
When working with user stories, some teams prefer to split them into tasks, but that's not mandatory, it's a preference. Sometimes it's even problematic because they can split the story horizontally in things like "build the database queries", "build the back-end", "build the front-end", "code review", "testing" etc, which can create development silos inside the team instead of everyone finding a way to collaborate on the story while at the same time finding the right balance to work individually. I for example don't like splitting stories into tasks. Some argue that tasks allow you to see progress better within the sprint, and your burn down chart looks better, but I don't find that useful because if you have a story split into 5 tasks, if you only finish 4 of them the story is not done either way. But I digress...
Getting back to the task being larger than a story, yes it's possible. Like I said, a task can be a product backlog item just like a user story can be. You could have some technical tasks in the backlog that are larger than some stories.
Say you have a story for doing login. The team might finish that in half a day. But they also have a technical task to update the framework libraries and some of its methods were deprecated in between versions. Now the team needs to make small changes here and there and that takes them the entire day. The framework task in this example is twice as large as the login user story.
You can sense the difference by understanding the reason for the existence of the User Story.
User Story represents the customer deliverable business value, and it is the basic item in the Product Backlog. The user story is written on the gathering requirement stage, and later injected into a specific sprint, after that the scrum team has to implement this story, the implementation is done by exploring the required technical tasks to that story.
I think the task is just a task, it is technical activity but User Story is a user wish. Find more Scrum.org
Remember: "user(!) stories" are exactly that ... a business/software requirement, expressed from the point-of-view of the user.
"Users," however, are fully entitled to "expect a system to 'work,' without concerning themselves as to how it works." They have no idea how the systems which they use are internally architected ... nor should they ever be expected to do so. Therefore, there must be a translation from "the user-centric domain" expressed by a "story," and the "technology-centric domain" that is required to implement it.
This translation-step consists of the formulation of tasks, test-plans, and so forth. All carried out by technical experts who are thoroughly familiar with the underlying system. It certainly will include purely-technical considerations that "the user knows not of, nor does he care." After all, his job is to drive the car, not to build it. His "stories," therefore, are merely inputs.
The value of the "user story" idea is that it strives to provides the user's inputs to the designers "in their own terms." Because otherwise it is very easy for a designer to lose sight of the user's perspectives. But, the idea was never intended to suggest that the end-user had somehow become a technical expert on the "guts" of any system.
