The Scrum Framework — Segunda edição

Este capítulo mantém o contexto histórico e prático de ensino da segunda edição. O currículo da terceira edição também está disponível no índice abaixo.

---

Histórias de Utilizador Scrum: Uma Visão Completa para uma Gestão Eficaz

Definição: Uma história de utilizador Scrum é uma descrição concisa e centrada no utilizador de uma funcionalidade pretendida num projeto Agile Scrum, frequentemente utilizada para descrever itens do Product Backlog; o framework não exige este formato. Escrita habitualmente da perspetiva do utilizador final, expressa o quem, o quê e o porquê de um requisito, destacando a colaboração e a comunicação entre equipas multifuncionais. Segue um modelo simples com um papel de utilizador (ator), uma ação ou objetivo e um benefício ou valor. As histórias facilitam o desenvolvimento Agile ao promover uma compreensão partilhada dos requisitos, o progresso incremental e a priorização baseada nas necessidades e no feedback dos utilizadores.

Histórias de Utilizador Scrum — É como criar o enredo de um filme para cada funcionalidade de que o software ou produto precisa, mas de forma mais curta e simples. Cada história traz uma personagem (o utilizador ou ator), um objetivo (a funcionalidade necessária) e a razão da sua importância (o benefício).Imagine agora estas histórias individuais a unirem-se numa rede interligada de desejos, expectativas e soluções: um backlog. Por surpreendente que pareça, gerir este backlog — priorizar e refinar — é como realizar um filme em que cada história é essencial, mas flexível. O International Scrum Institute está preparado para ser o guia ideal na sua jornada para dominar estas Histórias de Utilizador Scrum e a sua gestão eficaz.

Para escrever uma história de utilizador clara e eficaz em Scrum, utilize um formato como «Enquanto [papel], quero [capacidade] para [benefício]». Por exemplo: «Enquanto cliente, quero acompanhar facilmente o estado da minha encomenda para poder organizar o meu calendário em conformidade.»

Características das Histórias de Utilizador Scrum

Os itens do Product Backlog Scrum são frequentemente escritos como Histórias de Utilizador. A sua característica mais importante é contar uma pequena história sobre alguém que utiliza o produto. Contém um nome, uma narrativa breve e critérios e condições de aceitação para a sua conclusão. A vantagem das histórias é concentrarem-se exatamente no que o utilizador precisa ou quer, sem entrar nos detalhes da concretização.

Existem diferentes recomendações para definir Histórias de Utilizador. Um modelo possível é:

Enquanto [ator], [quero|devo] [ação] para [resultado]
Ou, numa versão mais curta:
Enquanto [ator], [quero|devo] [resultado]

Ator: A pessoa ou persona cuja necessidade é descrita, não a pessoa responsável pelo backlog. É frequentemente um utilizador, mas convém ser mais específico. Ao utilizar atores concretos (por exemplo, «Administrador», «Cliente com Sessão Iniciada», «Visitante Não Autenticado»), a compreensão torna-se mais fácil e a história ganha contexto.

Ação: Aquilo que o ator quer fazer. Se for uma ação obrigatória, pode ser precedida de «devo». Caso contrário, utiliza-se «quero».

Resultado: Aquilo que o ator pretende alcançar ao realizar a ação. É o resultado da execução da ação visto da perspetiva do ator.

História de Utilizador Scrum — Uma Visão Geral

No mundo dinâmico da gestão de projetos Agile, as histórias de utilizador são uma ferramenta essencial para comunicar eficazmente os requisitos dos clientes. Dão vida a requisitos que, de outra forma, seriam abstratos, apresentando-os da perspetiva do utilizador final.

São descrições concisas e informais de funcionalidades, escritas com as necessidades claras do utilizador final (ator da história) em mente, seguindo frequentemente a estrutura «Enquanto [utilizador/ator], quero [funcionalidade] para [benefício].» Este formato simples, mas poderoso, garante que cada história explica quem utilizará a funcionalidade, o que pretende e porquê. Ao reunir o «quem», o «quê» e o «porquê», as histórias proporcionam uma visão completa e abrangente do requisito.

Por exemplo, considere que os utilizadores finais de um site de comércio eletrónico precisam de uma pesquisa mais eficiente para encontrar produtos facilmente. A história correspondente poderia ser: «Enquanto comprador, quero uma pesquisa mais eficiente para encontrar rapidamente os produtos que me interessam.» Isto capta de forma sucinta a essência da funcionalidade da perspetiva do utilizador e especifica o seu valor.

Além disso, as histórias de utilizador são pontos de partida para conversas detalhadas entre partes interessadas, Product Owners e equipas de desenvolvimento. Iniciam discussões significativas sobre as necessidades dos clientes, facilitando a colaboração e a compreensão entre todos.

Além de serem ferramentas de comunicação, as histórias de utilizador são fundamentais para definir prioridades no Product Backlog. Ajudam a determinar as funcionalidades mais importantes para os utilizadores finais (atores) e aquelas cujo desenvolvimento deve ter prioridade.

O Papel das Histórias de Utilizador na Gestão de Projetos Agile

Compreender o conceito de histórias de utilizador na gestão de projetos Agile é muito vantajoso, pois proporciona às equipas uma compreensão clara das necessidades dos clientes. Também permite entregar valor excecional ao concentrar-se nas funcionalidades que realmente importam aos utilizadores finais.

É como construir uma casa: não começaria a construção sem uma planta nem sem compreender os requisitos do proprietário. Da mesma forma, as histórias de utilizador estabelecem a base e orientam a equipa ao longo do projeto, alinhando os esforços de todos com o cumprimento das expectativas dos clientes.

Dada a sua importância nos ambientes Agile, é fundamental que as organizações deem prioridade à formação das equipas sobre a criação de histórias eficazes. No International Scrum Institute, estão disponíveis recursos abrangentes para ajudar a dominar este aspeto fundamental da metodologia Agile. Estes recursos oferecem orientações para elaborar histórias refinadas e apresentam boas práticas de gestão no Product Backlog.

Agora que compreendemos profundamente a importância das histórias de utilizador na gestão de projetos Agile, vamos explorar, na próxima secção, a arte de criar histórias eficazes e com impacto.

Criação Eficaz de Histórias de Utilizador Scrum

As histórias de utilizador estão no centro do desenvolvimento Agile, e elaborá-las eficazmente é essencial para o sucesso de qualquer projeto. Apresentamos alguns princípios fundamentais a considerar na sua criação.

Compreender as Necessidades dos Utilizadores

Compreender as dificuldades e necessidades dos utilizadores finais é o primeiro passo fundamental para criar histórias com impacto. Dedicar tempo a colocar-se no lugar dos utilizadores e compreender profundamente as suas experiências, desejos e desafios garante que as histórias respondem a necessidades reais e entregam valor tangível. Técnicas como inquéritos, entrevistas ou estudos de observação permitem recolher informações diretamente dos utilizadores.

Estruturar as Histórias

SMART é uma perspetiva útil para discutir o resultado pretendido de uma história; não é um modelo obrigatório de Scrum:

• Específico — Defina o que precisa de ser feito
• Mensurável — Identifique como será medido o sucesso
• Alcançável — Garanta a viabilidade dentro das restrições existentes
• Relevante — Alinhe com os objetivos do negócio e as necessidades dos utilizadores
• Temporalmente Definido — Tenha um calendário claro para a entrega

Isto proporciona uma estrutura clara para a equipa de desenvolvimento e garante que cada história contribui diretamente para os objetivos do projeto e entrega valor real aos utilizadores finais.

Envolver a Equipa

Envolver toda a equipa na criação das histórias promove a colaboração e garante uma compreensão partilhada dos requisitos e objetivos finais. As perspetivas dos vários papéis, como programadores, designers, profissionais de testes e Product Owners, criam uma visão abrangente do que é necessário alcançar. Esta abordagem revela cedo conhecimentos valiosos e possíveis desafios, produzindo histórias mais refinadas que representam melhor a visão coletiva da equipa.

Agora que compreendemos a importância de empatizar com os utilizadores finais, estruturar eficazmente as histórias e envolver toda a equipa na criação, dispomos dos princípios fundamentais para elaborar Histórias de Utilizador Scrum apelativas e com impacto.

Com uma base sólida nos princípios de criação de histórias, exploremos agora técnicas para as priorizar e maximizar o seu impacto nos projetos Agile.

Técnicas de Priorização das Histórias de Utilizador

À medida que o Product Backlog cresce, torna-se essencial priorizar eficazmente as histórias. Afinal, nem todas as funcionalidades têm a mesma importância, e algumas podem influenciar mais a satisfação dos clientes ou o desenvolvimento do produto. Apresentamos duas técnicas poderosas que podem ajudá-lo a tomar decisões informadas e maximizar o valor entregue pela equipa Agile.

Método MoSCoW

A técnica de priorização MoSCoW classifica as histórias de utilizador em quatro categorias importantes: Tem de Ter, Deve Ter, Pode Ter e Não Terá Desta Vez. Esta abordagem simples, mas eficaz, ajuda a identificar as funcionalidades essenciais para desenvolvimento segundo a urgência e a importância.

• Tem de Ter: São funções ou funcionalidades inegociáveis, indispensáveis para o funcionamento básico do produto ou para satisfazer necessidades fundamentais dos utilizadores. Sem elas, o propósito principal do produto ficaria comprometido.
• Deve Ter: Representam funcionalidades importantes, mas não essenciais para o lançamento inicial. Contribuem para a completude do produto e podem ser adiadas, se necessário.
• Pode Ter: São funcionalidades desejáveis, mas opcionais, que melhorariam a experiência do utilizador ou acrescentariam valor, podendo ser adiadas sem afetar as funções centrais do produto.
• Não Terá: Funcionalidades consideradas desnecessárias no momento e deliberadamente excluídas do âmbito atual do trabalho.

A classificação clara do método MoSCoW permite que as partes interessadas alinhem as expectativas com a equipa Agile e ajuda a alcançar consenso sobre o que desenvolver primeiro.

Modelo de Kano

Além de MoSCoW, considere utilizar o modelo de Kano para classificar as histórias segundo o impacto na satisfação dos clientes. Este modelo distingue três tipos de atributos: básicos, de desempenho e de encantamento.

• Atributos Básicos: São requisitos fundamentais que os clientes esperam e frequentemente tomam como garantidos. Quando satisfeitos, não aumentam necessariamente a satisfação, mas a sua ausência pode causar insatisfação.
• Atributos de Desempenho: Estes atributos relacionam-se diretamente com a satisfação do cliente: quanto melhor o desempenho, maior a satisfação. Contudo, aplicam-se rendimentos decrescentes, pois melhorias excessivas nestes atributos nem sempre aumentam o encantamento do cliente.
• Atributos de Encantamento: Estes atributos podem surpreender e encantar os clientes quando presentes, mas a sua ausência não afeta significativamente a satisfação.

Ao identificar a categoria de cada história, os Product Owners compreendem melhor as prioridades dos utilizadores, podendo tomar decisões informadas sobre o desenvolvimento de funcionalidades alinhadas com as suas necessidades e desejos.

Utilizar estas técnicas de priorização garante que a equipa Agile se concentra em entregar valor através de funcionalidades realmente importantes, evitando esforço desperdiçado em elementos não essenciais e aumentando a satisfação global dos clientes.

Depois de compreendermos técnicas eficazes de priorização, é altura de explorar o papel fundamental das partes interessadas na definição e no refinamento destas histórias.

O Papel das Partes Interessadas nas Histórias de Utilizador Scrum

No mundo Scrum, as partes interessadas são como estrelas orientadoras. São quem conhece exatamente os desejos dos utilizadores e as necessidades do negócio. O seu contributo é essencial para criar histórias que reflitam verdadeiramente os requisitos e expectativas de ambos. Sem o seu envolvimento, é como conduzir sem mapa: sem direção e com grande probabilidade de se perder.

Por exemplo, imagine desenvolver uma nova aplicação bancária móvel. As partes interessadas representam o marketing, o apoio ao cliente, a segurança informática e vários departamentos tecnológicos. Cada uma traz uma perspetiva única que, em conjunto, proporciona uma visão completa do que a aplicação precisa de fazer. O marketing poderá destacar uma interface intuitiva e apelativa, o apoio ao cliente priorizar uma interação fluida e a segurança informática concentrar-se em protocolos robustos de segurança.

Assim, tal como é necessária uma comunidade para educar uma criança, são necessários todos estes pontos de vista para dar vida a uma história de utilizador com sucesso.

Envolver as partes interessadas no refinamento das histórias ajuda de várias formas:

• Relevância no Mundo Real: Proporcionam informações sobre situações reais e necessidades dos utilizadores, garantindo o alinhamento das histórias com os requisitos práticos do negócio.
• Ciclo de Feedback: Ao envolver ativamente as partes interessadas, as equipas garantem a recolha de feedback em cada etapa, permitindo melhorias iterativas.
• Alinhamento com os Objetivos do Negócio: As partes interessadas ajudam a garantir a ligação das histórias a objetivos empresariais mais amplos, apoiando decisões mais estratégicas.

Por exemplo, se as partes interessadas não participarem na definição das histórias da aplicação bancária, poderá haver o risco de criar funcionalidades que não correspondem às expectativas dos clientes ou não cumprem as normas regulamentares. Isto poderá provocar atrasos ou retrabalho dispendioso mais tarde.

Além disso, envolver as partes interessadas desde o início não só promove um sentido de responsabilidade e envolvimento como cria um ambiente em que a colaboração e a comunicação prosperam.

É agora claro por que motivo o envolvimento das partes interessadas no refinamento das Histórias de Utilizador Scrum é decisivo. As suas perspetivas e orientações conduzem as histórias ao cumprimento dos objetivos do negócio e à resposta eficaz às necessidades dos utilizadores.

Depois de compreendermos o papel indispensável das partes interessadas na definição das histórias, passemos à arte de estimar a complexidade para uma gestão Scrum eficaz. (Saiba mais sobre estimativa de esforço em Scrum)

Estimativa da Complexidade para uma Gestão Scrum Eficaz

Dimensionar uma história de utilizador pode ajudar a compreender o esforço e a complexidade. As estimativas apoiam decisões; não são garantias, e Scrum não prescreve uma técnica específica. Um dos métodos mais populares é o Planning Poker, que utiliza um baralho de cartões com números que representam diferentes níveis de esforço ou complexidade.

Os membros discutem uma história e escolhem individualmente um cartão que representa a sua estimativa. Os cartões são revelados em simultâneo e discutem-se as diferenças significativas. O processo continua até alcançar consenso sobre a complexidade da história.

Assim, considera-se a opinião de todos e incentiva-se a participação ativa. As estimativas partilhadas ajudam a compreender melhor as perspetivas dos colegas e podem até revelar complexidades ou desafios da história anteriormente despercebidos.

Considere uma história sobre criar uma página de início de sessão de uma aplicação. Um membro pode considerá-la simples e sugerir 3, enquanto outro considera as várias regras de validação necessárias e propõe 8. Ao discutir estas diferenças abertamente, a equipa compreende melhor a tarefa e pode identificar componentes que não tinha considerado.

As estimativas de esforço do Planning Poker são valiosas não só para o Sprint Planning, mas também para distribuir recursos e compreender a capacidade da equipa. Durante o planeamento, o Product Owner utiliza-as para priorizar histórias com base na complexidade e no potencial de entrega de valor.

Estas estimativas são fundamentais para determinar o trabalho que pode ser realisticamente assumido num Sprint, evitando compromissos excessivos, esgotamento ou problemas de qualidade. Também ajudam a identificar dependências entre histórias, permitindo uma melhor sequência e gestão das dependências.

Estimar eficazmente a complexidade com técnicas como Planning Poker é fundamental para manter a transparência, promover a colaboração e tomar decisões informadas na gestão de projetos Scrum.

Com uma compreensão clara da influência das estimativas de complexidade na gestão Scrum, exploremos agora como utilizar histórias de utilizador para uma gestão eficaz do Product Backlog.

Utilizar Histórias de Utilizador Scrum na Gestão do Product Backlog

As histórias são a voz dos clientes, orientando a equipa de desenvolvimento na criação de produtos alinhados com as necessidades dos utilizadores finais. Proporcionam um contexto valioso, garantindo a compreensão do que se espera e do valor que acrescentará. Quando bem utilizadas, clarificam a comunicação e simplificam as decisões através de uma compreensão abrangente dos requisitos, essencial para manter um Product Backlog bem organizado e refinado.

Na prática, é útil envolver várias partes, como clientes, utilizadores finais, Product Owners e Developers, na elaboração das histórias. As perspetivas diversas garantem a inclusão de requisitos e casos de utilização variados, proporcionando uma visão mais abrangente das funcionalidades.

Por exemplo, num projeto de desenvolvimento de uma aplicação bancária, uma história poderia representar a necessidade de um cliente transferir dinheiro entre contas sem dificuldades. Isto ajuda a compreender as funções específicas necessárias e o possível impacto na experiência do utilizador.

Além disso, as histórias são dinâmicas e podem ser continuamente refinadas e repriorizadas segundo a evolução das necessidades dos clientes e as tendências do mercado. Ao atualizá-las e reavaliá-las regularmente, o Product Backlog mantém-se ágil e adaptável às exigências do negócio.

É fundamental que cada história mantenha clareza e especificidade quanto à funcionalidade que representa. Uma história bem estruturada segue normalmente o formato: «Enquanto (papel), quero (funcionalidade) para (benefício).»

Além disso, incluir critérios de aceitação em cada história acrescenta detalhe, definindo condições claras que devem ser cumpridas para considerar a funcionalidade concluída. Estes critérios são medidas objetivas do cumprimento do propósito pretendido, alinhando a equipa e as partes interessadas quanto aos resultados esperados.

No exemplo bancário, um critério de aceitação pode especificar que, ao transferir dinheiro entre contas, o sistema deve validar as credenciais das contas e gerar prontamente comprovativos da transação. Isto garante uma compreensão partilhada do que constitui uma implementação bem-sucedida desta história específica.

Aproveitar eficazmente as histórias permite que os Product Owners clarifiquem os requisitos dos clientes e que as equipas desenvolvam soluções ajustadas às necessidades dos utilizadores finais. Ao refiná-las consistentemente à medida que o contexto empresarial evolui, as organizações podem manter um Product Backlog adaptável, preparado para responder às exigências dinâmicas do mercado.

Ao tirar partido da versatilidade das Histórias de Utilizador Scrum, as organizações garantem que o Product Backlog continua a responder à mudança constante das necessidades dos clientes e da dinâmica do mercado. Esta adaptação é essencial para entregar produtos que correspondam realmente aos utilizadores finais.

Quais são os principais componentes de uma história de utilizador Scrum?

Resposta: Os principais componentes incluem o papel ou persona, uma descrição breve da funcionalidade pretendida e os critérios de aceitação. Ajudam a compreender a perspetiva do utilizador final e fornecem orientações claras para o desenvolvimento. Segundo um inquérito da Stack Overflow em 2023, 87% das equipas Agile destacaram a importância de histórias bem definidas para uma gestão eficaz do backlog.

Como contribui uma história de utilizador para o Sprint Planning e a priorização em Scrum?

Resposta: As histórias de utilizador contribuem para o Sprint Planning e a priorização em Scrum ao proporcionar uma compreensão clara da perspetiva, necessidades e resultados pretendidos pelo utilizador. Permitem alinhar os esforços da equipa com esses objetivos, ajudando a determinar quais devem ser tratadas primeiro segundo o valor e a complexidade. Segundo um inquérito da VersionOne em 2022, as equipas que priorizam eficazmente as histórias durante o Sprint Planning registam maior produtividade e satisfação dos clientes.

Qual é o objetivo de uma história de utilizador na metodologia Scrum?

Resposta: O objetivo de uma história de utilizador em Scrum é captar os requisitos e necessidades dos utilizadores finais ou clientes. Funciona como ferramenta de comunicação entre a equipa e as partes interessadas, permitindo melhor compreensão e colaboração. As histórias concentram-se em entregar valor ao cliente e ajudam a priorizar itens do backlog segundo o feedback dos utilizadores e o valor de negócio. Segundo um inquérito da Scrum Alliance, 76% dos participantes concordaram que as histórias melhoraram a capacidade de a equipa entregar valor aos clientes.

Como escrever histórias de utilizador eficazes para desenvolvimento Agile?

Resposta: Para escrever histórias eficazes no desenvolvimento Agile, concentre-se nos «Três Cs»: Cartão (descrição breve), Conversa (discussão dos detalhes) e Confirmação (critérios de aceitação). Mantenha as histórias concisas, específicas e priorizadas segundo o valor para o cliente. Segundo um inquérito da VersionOne, 65% das equipas Agile consideraram que manter as histórias pequenas e bem definidas contribuiu para o sucesso do projeto. A colaboração regular entre Developers, Product Owners e clientes também é fundamental para garantir compreensão partilhada e alinhamento dos requisitos.

Existem boas práticas ou erros habituais a considerar ao utilizar histórias de utilizador em Scrum?

Resposta: Sim, existem várias boas práticas e erros habituais a considerar. As boas práticas incluem definir claramente o papel, o objetivo e o benefício de cada história, priorizar segundo o valor e a complexidade, envolver toda a equipa na redação e estimativa e refinar e atualizar regularmente o backlog. Os erros habituais incluem histórias demasiado detalhadas ou técnicas, não envolver as partes interessadas, não dividir histórias grandes e não atualizar nem refinar regularmente o backlog. Segundo um inquérito da Scrum Alliance, as equipas que seguem estas boas práticas comunicaram melhor comunicação (74% dos participantes), maior alinhamento com os objetivos do negócio (68%) e maior satisfação dos clientes (62%).

Recapitulação das Histórias de Utilizador Scrum

Nas Histórias de Utilizador Scrum, um aspeto fundamental é o mapeamento cuidadoso dos requisitos, em que cada história é uma parte valiosa do desenvolvimento iterativo. Estas histórias, frequentemente consideradas os elementos constituintes dos épicos, contribuem para o sucesso global de uma iteração ao definir claramente algo significativo para a equipa desenvolver. Identificar épicos, compostos por várias histórias, garante uma abordagem abrangente ao planeamento e à execução do projeto. Ao longo deste artigo, explorámos os benefícios das histórias na metodologia Agile, mostrando como melhoram a comunicação na empresa e simplificam a entrega de informações valiosas.

Compreender a importância das histórias implica reconhecer o seu papel na entrega de benefícios tangíveis tanto à equipa de desenvolvimento como aos utilizadores finais. Os exemplos concretos deste artigo ilustram como facilitam estratégias eficazes de testes, garantindo que cada entrega cumpre os critérios especificados. Ao dividir funcionalidades complexas em componentes geríveis, as histórias permitem que a empresa percorra o desenvolvimento iterativo com maior facilidade. Esta abordagem promove a colaboração e permite adaptação à evolução dos requisitos ao longo de cada iteração.

Concluindo, as histórias de utilizador são um elemento decisivo no framework Agile, oferecendo uma abordagem estruturada à gestão de projetos. Seja para dividir um épico em partes geríveis, facilitar o planeamento eficiente de iterações ou melhorar a comunicação na empresa, são fundamentais para obter resultados bem-sucedidos. Como vimos nos exemplos e nas discussões sobre estratégias de testes, incorporar histórias acrescenta valor ao desenvolvimento ao garantir que cada entrega está alinhada com os objetivos globais. Para quem pretende aprofundar os conhecimentos sobre metodologias Agile, o International Scrum Institute oferece uma oportunidade valiosa de inscrição numa certificação Scrum, capacitando as pessoas para lidar com o panorama dinâmico da gestão de projetos com conhecimento e confiança.