Scrum: Who writes the TOR? How detailed?

Question

Agile

Hello colleagues!
I got on the difficult path of implementing agile.
Everything seems to be clear, there are some stones, which some call not step over (for example, the fact that most of the developers are remote and often change). But there are already cases for solving these problems, and we do not give up.
But here a question arises, the answer to which I have not seen in the studied manuals. Everyone is talking about backlogs, sprints, retrospectives, etc.
But how is TK written?
Well, there is a user story, and the programmer wants yuml, and other complex things.
In your team, who writes the TOR?
How detailed is it?
How is this work evaluated?
Thank you very much for the replies.

Answer 1

But how is TK written?

no way.
he does not want uml and other complicated things. There is usually little value in this within the scrum methodology.
Well, that's enough, there is a user story, you can write a technical specification for this user story, you can write a feature spec using GivenWhenThen gizmos ala gherkin or just use gherkin for the desired level of feature detail. The backlog consists of a bunch of these small TK. They are for good made up by the product of the owner or business analyst or someone else. A good practice is grooming or backlog renewals, these are rallies where the backlog is cleaned. Well, that is, we take, say, a few features from the backlog and conduct additional decomposition, ask questions, etc. so that by the time these features are taken into the sprint, everything is already in hand.
ps Why do you need Scrum? Take kanban to start with and add rules from scrum if you like.

Answer 2

With this technique, I personally immediately apply interface design if I am writing for the web or a structure if it is software (in any case, a story)
After that, I already describe the elements, pages, layout and functionality in more detail.
The structure may change during the 15-day cycle.

Answer 3

TK is written by people who are called analysts. They are a layer between customers and programmers, they know both the subject area and the basics of programming.
That's just the complex things that the programmer wants, they produce.

Answer 4

I write myself.
Not so long ago I started doing this because of the state order.
A bunch of approvals, documents through the security service, then approval of the contract by lawyers (by the way, it took 24 days), then accounting, then only signing and payment.
In fact, the guys are adequate. A Brief was drawn up * Speaking of the Brief with us *
I give the Brief to be filled in by the Customer, there are questions ala, the purpose of creation, identification of budgets, a little about the blocks
that the Customer wants to see such as (News, catalog, etc.) Way of further project management (give us for support or by the manager, etc.)
The technical assignment had to be written by myself. The first version was water. She was not approved and immediately made it clear that everything should be scheduled. Starting from what a site is, Bitrix, customization, etc. There are also clear stages of work and what they get after each stage.
The contract is very thoughtful, each paragraph refers to another or annexes to the contract.
Such an experience.)
Writing is not difficult, at first I thought why do it, but disputes often arise. Like, let's make an online store out of a business card, and this is other money already that no one wants to pay.
Thus, I cover the "rear" for myself and the customer understands what will happen in the end.
There are no innuendos. And accordingly there are no problems.

Answer 5

TK? - there is no TK there, with such a development methodology.
there is a vision of what we want to get, every iteration (week / month), you think about what tasks you will solve to achieve the vision, where you will move on, adjusting for feedback from customers.
and it’s not a fact that you’ll come to what you originally planned, it’s the very vision of where you’re going, it can change every iteration.