Pessoalmente, eu não alocaria recursos para criar histórias de usuário de engenharia reversa em um aplicativo existente, tudo de uma só vez.
Comece com as novas solicitações para desenvolver boas práticas com esse processo (obtendo feedback de clientes, gerando histórias de usuários, usando-as para desenvolvimento e finalmente tendo recursos testados e aprovados.). Todos devem se tornar fluentes e eficientes.
Quando todos os envolvidos estiverem proficientes no processo de história do usuário, colete histórias adicionais sobre recursos ou seções do aplicativo relacionadas aos novos recursos. O objetivo aqui é identificar o que os usuários realmente querem (talvez um recurso possa ser removido?), Então ninguém acidentalmente tira algo necessário. Eu acho que este é um método mais eficiente porque o desenvolvedor está se familiarizando com uma certa parte da base de código já. Use esse conhecimento para desenvolver mais especificações.
Lembre-se de que as histórias dos usuários são o que o usuário quer do ponto de vista dele. Não há nada sobre como isso é feito. Um conjunto de testes pode ajudar a realizar isso ou a documentação de requisitos adicionais, mas você precisa ter uma equipe com alguma fluência nessa área. Equipes que lutam com testes de escrita, assim como escrever histórias de usuários, não serão capazes de criar algo muito útil. Eles estão lutando para apenas fazer funcionar.
A chave é garantir que a adoção desses novos processos (histórias de usuário e testes) seja bem-sucedida. Leva tempo. Se você ainda está praticando essas coisas, não é provável que você tire o máximo proveito delas. Todos ficarão frustrados com o processo e isso acabará sendo um desperdício.