The Dev Team writes the technical things. Scrum helps you a bit but not much with the technical breakdown resp. getting started on a User Story. Scrum is almost What-World-only. The technical breakdown is How-World.
The breakdown provided by Scrum is:
- User Story -> Acceptance Criteria
The breakdown people often use on top of this is:
- Epic -> User Stories
- User Story -> Subtasks
- Acceptance Criteria -> Acceptance Tests
Plus, the team might write Technical Tasks for things they know need to be done (i.e. install IntelliJ IDEA for everyone at the start of the project) but which have no Business Value.
For further guidance on how to breakdown work, look out for XP (Extreme Programming), Clean Code, Pragmatic Programming, Software Engineering, CRC-Cards, OOP / OOA / OOD, Design Patterns, Refactoring, Working Effectively with Legacy Code, TDD (Test-Driven Development), BDD (Behavior-Driven Development), ATDD (Acceptance-Test Driven Development).
How Scrum Thinks
What-World and How-World
There is a What-World and a How-World. As you felt correctly, User Story is for Users, generating Business Value aka Secondary Value in the What-World. Scrum is mostly What-World only. It says little to nothing about the How-World, basically no more than "How-World is the responsibility of the Dev-Team".
User Story vs Task
Usually, Backlog Items which are for the How-World are not called User Story but Technical Task or Subtask. Many tools allow breaking down the User Story from the What-World into Subtasks in the How-World.
How Scrum Helps and Where that Help Ends
The help of Scrum for the How-World ends at a few points in the Sprint Planning Meeting:
- [Sprint Planing Meeting] The team discovers misunderstanding of the story if different team mates come up with different Story Point estimates during the Planning Poker -> Discussion.
- [Definition of Ready] The team does not accept User Stories which are too big (Story Points too high). A rule of thumb found in many Definition of Ready is that the Story Points must be less than half the team's velocity.
- [Definition of Ready] The team does not accept User Stories without sufficient description of Acceptance Criteria. Acceptance Criteria are sufficient if the team has enough confidence on how to start writing the Acceptance Tests.
A few tips on the Level of Scrum
I found it helpful to do a break-down of User Stories into Subtasks during the Backlog Refinement meetings or at least the second part of the Sprint Planning Meeting (for some teams Sprint Planning 2 Meeting).
With inexperienced teams I found it helpful to strive for Atomic User Stories during the Backlog Refinement and Sprint Planning. An Atomic User Story is a User Story which cannot be broken down further into Smaller User Stories without loosing its Business Value entirely. In general User Stories don't need to be Atomic, I just found that it helps me with inexperienced teams.
And don't do "(Architecture|Design|Implementation|Test) of Feature X" as User Stories. I recommend that you even try to avoid this as a Subtask.
If I have Atomic User Stories and they seem to need further breakdown apart from the Acceptance Criteria to be implemented, it means to me that something is not working at the optimum level. Either the architecture is wrong / too complicated, i.e. technical instead of business-oriented. Or the team is inexperienced. Or both. In any case, action would be required to improve the situation by training and spreading knowledge.
The Scrum Master beyond Scrum
Today, the Scrum Master is mostly understood as a Managerial Role, and that's bullshit. Originally, the Scrum Master was, and I advocate this, a Technical Role, not a managerial role, just like the Coach in XP.
It is all too easy to rely on Scrum and the Scrum Master and thus fall into a huge gap because Scrum says almost nothing about the How-World.
Rotating Scrum Master
Ideally, the Scrum Master rotates among those experienced developers who also have sufficient managerial and communication skills until everybody in the team is living "Inspect and Adapt" so deeply by heart that the Scrum Master becomes redundant; nobody and everybody would be Scrum Master at the same time.
But beware, Scrum Mastery is more like cooking, not like cleaning the table and washing dishes. You might want to rotate who cleans the table and washes the dishes, as everybody could do that. But you wouldn't want to rotate the cooking onto everyone, because there are people who can't cook or don't like cooking, and you want to eat good food.
The good thing about rotating the Scrum Master between expert developers is that the team is more likely to learn about more methods.
The Self-Organizing Team
From Scrum's perspective, the team must find out itself, ideally with the help of the Scrum Master.
Scrum also just talks of the Dev Team. Roles like Architect or Lead Engineer do not exist in Scrum. That doesn't mean that they're forbidden, it only means that Scrum doesn't say anything about them. Scrum proclaims a Self-Organizing Team, which means if the team declares an Architect, the team has an Architect. That's not defined by Scrum, but it's compliant with Scrum. I'm not proclaiming dedicated Architects (I worked as a designated Architect for years, and although I liked it, I'm fundamentally against the idea of a designated Architect), just giving an example.
User Stories have Acceptance Criteria. These Acceptance Criteria are turned into Acceptance Tests
For a list of more stuff for breakdown, see How to break up a programming project into tasks for other developers?
Hope this helps.