User stories can be considered as the most used form to manage requirements in Agile. However, as often with agile concepts Agile that look simple in theory, using them in practice generates many questions: What should user stories contain? When should they be ready to be developed? What is an optimal backlog size? This is the type of issues that Allan Kelly discusses in his interesting Little Book about Requirements and User Stories.
Many Agile coaches are former software developers, some are not. But when technology moves on, well known Agile approaches can be challenged. Applying the Agile approach of vertical story slicing on microservices is one such example. This talk explains on how as Agile coaches we can coach in technical areas where technology may have moved on, thus challenging the perceived coaching approaches to helping teams become self-organising.
User stories are one of the main format to record user needs in the Agile world. There is however a debate on the amount of information that should be available to the Scrum team before starting the sprint. In this article, Zuzi Šochová recommends to minimize the size of user stories and to define simple conditions of satisfaction instead of writing acceptance criteria.
Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed product backlogs.
We all know the “Definition of Done” used in Scrum for items that should be potentially shippable to the customer at the end of the sprint. In his book Essential Scrum, Kenneth Rubin discusses the “Definition of Ready” that applies to product backlog items that should be ready to be developed before the start of the sprint.
If user stories are the start of the conversations to define user requirements, Scrum teams can also use other tools to obtain a more precise definition of these requirements. In the article “When and How to Create Customer Journey Maps”, Kate Williamson presents the concept of customer journey map, the visualization of the process that a person goes through in order to accomplish a goal, and when and how to use them.
It can be complicated to involve the whole team to facilitate product backlog refinement and take part in requirements discussions. I would like to suggest a structure of the PBR (product backlog refinement) meeting that will encourage everybody to speak up and share their ideas on functionality.
Scrum Expert Copyright © 2009-2023 Martinig & Associates