Analysis
When refining a large user story during the sprint planning, should I create subtasks on the story, relating to frontend, backend, integration etc, and accept that "visually", an increment will only be reached when all the story's subtasks are completed.
There are a number of anti-patterns embedded in this quested. In no particular order:
- Large stories violate INVEST. Regardless of framework, stories should be as small, testable, estimatable, and valuable as possible without wandering off into the technical weeds.
- You should not be decomposing backlog items or features into stories or tasks. That's the development team's job, and it's up to them to figure out who needs to do what to meet the defined goals of a given feature.
- Assuming you're doing something vaguely Scrum-like, you're missing the forest for the trees. The goal is to achieve the Sprint Goal (or whatever your framework uses as its cohesive objective for the iteration) rather than earning victory points for every step you take along the journey.
- Agility generally takes a binary view of "done." Either a useful increment of value is produced at the end of the value stream or it is not. An increment is either done or not-done; you don't get partial credit if 80% of everything is 60% done.
- Sub-tasks might be useful as a checklist for a plan, but if it's not reflective of your Definition of Done for the work item then it's just another way of avoiding active collaboration between the members of the development team.
Collectively, this set of patterns inherently values effort expended rather than outcomes. You get what you measure, so if you continue with this pattern you can expect lots of time and effort to be expended on defining and executing tasks and sub-tasks, but useful outcomes from the process will be few and far between.
Recommendations
JIRA isn't inherently a bad tool, but it is most definitely not an intrinsically agile tool. It's fundamentally a ticketing system, and unless you replace people with teams as the fundamental unit of assignment in JIRA it fosters a culture of "tossing things over the wall" and passing things around by individual assignment. Don't fall into that trap!
JIRA has the concept of epics, features, stories, and tasks. It may also treats bugs, chores, and other such things differently if so configured. That's fine and dandy if that approach adds value to the product, but most of the time it just ends up being used as a time-based task-tracking system. If that's the case, then whether or not there's value in tracking sub-tasks depends on whether tracking sub-tasks is required by the management of a non-agile company culture, or is somehow valuable as part of the development team(s) working agreements with one another.
When talking specifically about web development, it's rare for a meaningful increment to sit in only one of the application's many skill domains:
- front-end
- back-end
- UI/UX
- database
- networking
- QA
- CI
- operations
- etc.
Ideally, your features should represent vertical slices of functionality across all of these domains. It may not have to if the work is to move some widget three pixels to the left, but does that by itself usually add significant value to the product? Probably not.
So, focus on defining features that deliver a useful bit of "what." What new thing should the system do? What old thing should the system do differently? What bad thing should the system stop doing at all? Anything more granular is not really a "feature."
Stories are about how. In order to deliver the feature, how will the development team provide the new, changed, or improved functionality? Who needs to be involved? How will the entire feature be tested to ensure it is fit for purpose and meets the Definition of Done? Those things should be left to the team to decide as long as the features are delivered on a regular cadence more often than not. Any additional granularity should be a process issue for the team to manage themselves.
The triple net here is that fundamental answer to your question is to re-evaluate why you are interested in tracking anything smaller than a feature. If there's a legitimate reason, discuss it with your team and hammer out a working agreement. If not, let your development team hammer out whatever process works best for them.
Teach your team (and your stakeholders!) to value outcomes rather than effort expended. Once you have successfully made this frame shift as a team and as an organization, you can then tune JIRA to fit your process instead of contorting the process around the tool.
