I know that in Scrum this is the hierarchy for defining things to do:
Theme -> Epic -> Story -> Tasks
My question is. I got some tasks that I consider story-independent, for example, configuring some stuff in the production environment for a web app.
Can I define Tasks that are not related to a Story?. Or, how is the correct way to define this?.
Thanks in advance!!!.
"What" goes on the Product Backlog. "How" goes on the Sprint Backlog.
The Product Owner never handles anything more granular than a user story. The Product Backlog should never contain tasks or implementation details.
The Sprint Backlog is where tasks live. In Scrum, stories define what functionality should be delivered, not how that functionality is to be implemented. That level of detail is the sole province of the Development Team, who decompose stories into tasks for the Sprint Backlog.
I got (sic) some tasks that I consider story-independent, for example, configuring some stuff in the production environment for a web app.
You are defining stories incorrectly. A user story isn't just a product feature; it's any project-related work above the level of the implementation-specific details. Ideally, a story captures value and deducts from the pool of available team capacity or resources.
In this case, your story should read something like:
As a DevOps engineer,
I need to reconfigure the web application
to reduce its memory footprint for use on small Amazon EC2 instances.
Whether or not this is your actual use case, it clearly shows that what you're calling a "task" is really a legitimate user story that can add value to the project. By placing it on the Product Backlog, you have correctly made this story a visible cost to the project. No invisible work, ever!
"Tasks" should never be created except as a descendant of a Product Backlog item. All tasks on a Sprint Backlog should be traceable to a Product Backlog user story or the Definition of Done. It's never okay to put unrelated tasks on the Sprint Backlog; doing so is a project smell, and generally leads to invisible work or hidden project costs that are kept "off the books."
Just don't do it!
Can you? Of course you can. Do whatever you want. Don't treat Scrum like a process to follow.
Should you? It depends. I prefer not to. I prefer to find a story that will force me to perform the task, then make the task part of that story. If I can't find an urgent story that forces me to do the task, then perhaps I don't need to do that task now. The longer I defer doing that task, generally speaking, the better.
So I have to ask: why would you configure stuff in a production web app except to be able to deliver a story? I know you might think "I'll have to do this anyway, so I'll do it now", but I find value in challenging that thinking. You'd be surprised what we can defer until later. You'd be surprised what we can avoid doing altogether.
Even if you believe that this configuration task has to happen before you can release any other story, I would still recommend doing it as part of completing a story. You might even find that you can do 20% of the configuration now--just enough to deliver the current story--and do the rest later. Even if splitting up the configuration work doubles the cost of that work, if you can complete stories by doing only 50% of the configuration work, then you can release those stories sooner, and releasing stories sooner (not necessarily for the least cost) lies at the heart of the philosophy of Scrum.
I have to add that all this assumes two things:
Your organisation wants to practise releasing features sooner in order to eventually start collecting revenue sooner from releasing features. (Even if they can't realise that value now, they need to start practising if they ever want to become skilled at it.)
Your organisation values earning revenue sooner at all. If they don't, then why the hell are they doing Scrum?!
