One of values of the Manifesto for Agile Software Development is that you should prefer “responding to change over following a plan”. This introduces a lot of uncertainty in Scrum projects. In his book “Executable Specifications with Scrum”, Mario Cardinal explains that to manage this uncertainty, you have to build your project on a stable platform.
This presentation will help you understand what it takes to run a successful agile release planning meeting. The release planning is the “pacemaker” of enterprise agility and the Agile Release Train (ART) which aligns the Agile program to a common mission. Based on nearly a decade of experience, Dean Leffingwell and Scaled Agile have developed a process which has worked with small trains of 40 people to larger trains of 180. This video explains what it takes to run a successful Agile release planning meeting from a scaled point of view (100′s of teams).
Most of the Scrum teams use a task board to visualize their activity and progress with task cards. In these two blog posts, Keith Clinton, the author of Agile Game Development with Scrum, discusses the concept of feature boards and feature cards.
The definition of “Done” (DoD), which means that a feature is ready for delivery, is a concept often discussed in Scrum. In this blog post, George Dinwiddie discusses the concept of “Ready” that apply to user stories that are ready to be developed.
User stories and their format defined by Mike Cohn “As a , I want so that .” are a classical way to record requirements in Scrum project. In his blog post, Alan Klement discusses a new format that he called “Job Stories” with the format “When … , I want to … , so I can … .”
Agile practitioners are aware that Scrum has three roles: developer, ScrumMaster and product owner. In his book “Executable Specifications with Scrum”, Mario Cardinal also discusses how you can use the role notion in Agile to better understand stakeholders that have a different perspective, a concept that is also named “personas”.
Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
Scrum Expert Copyright © 2009-2023 Martinig & Associates