Olá Eduardo,
a ideia de uma User Story é que ela seja um convite para uma conversa. O que acontece é o cartão terá até pouca informação se parar para pensar, ele traduz a necessidade do que precisa ser implementado do ponto de vista de um usuário. A ideia é que ao invés de fazer todo um levantamento de requisitos e casos de uso, durante a Planning todo está ali para conversar sobre o que precisa ser feito. Então o P.O. explica do ponto de vista do negócio a história e os devs discutem tecnicamente o que precisa ser feito, inclusive quebrando em tarefas (funcionais) sobre o que será desenvolvido. A ideia é ocorrer um alinhamento entre todas as pessoas sobre esta história, inclusive o planning poker auxilia nisso. E caso durante a fase de desenvolvimento os devs tenham alguma dúvida sobre a história, eles podem conversar com os outros integrantes do time. Por exemplo, se a dúvida for técnica eles podem verificar com outro dev, e caso seja de negócio ele pode falar com o P.O.
Então a ideia na verdade da user story é tirar um pouco a necessidade de escrever documentos especificando o que precisa ser feito e trazer mais conversa cara-a-cara para evitar telefones sem fio e promover uma maior auto-organização. Mas caso a sua empresa exija um documento como casos de uso ou algo do gênero, como o Scrum é um framework, nada impede que se adapte e encaixe esta documentação no processo também no ponto em que sentir necessidade.
O mesmo vale para documentações mais de arquitetura e código, como diagramas de classe, banco, etc. Caso o time sinta a necessidade de ter um documento desses ele pode colocar em seu processo, como uma das fases do critério de pronto, por exemplo. O ideal é que para garantir que estas documentações ficarem sempre atualizadas e não tomarem muito tempo do time, é que na medida do possível elas sejam automatizadas. Um exemplo de documentação que muitos times ágeis acabam usando são testes automatizados.
E quanto a gestão desta documentação, como comentei acima, para evitar muito gasto de tempo é bom automatizar o que for possível. Se precisar ser manual, o ideal é que seja responsabilidade do time como um todo atualizá-la. Por exemplo, a cada sprint pode se definir um guardião das documentações que irá atualizá-las e este papel fica rodando entre as pessoas.
