Writing effective user stories on Agile projects requires collaboration between the product owner and team. The effort involves agreeing on the depth of technical detail in the story, ensuring that epics are appropriately broken down, and adding acceptance criteria. Let’s look at some helpful examples for each step.
There are many ways that story points are often used incorrectly by well-meaning teams. In the fourth installment of our series, we look at two more agile anti-patterns that seem like good ideas but aren’t: allowing everyone to have a vote, and playing “Go Fish” during planning exercises.
In agile projects, most requirements start out as epics, which are too big to be addressed in a single sprint. Let’s look at some examples of how epics are broken down into manageable stories through team and user collaboration, and how acceptance criteria add important details.
Requirements in Agile environments are handled very differently than in projects following linear processes. In Scrum, requirements are collected and shared through user stories, which have a precise format that invites conversation and collaboration. Here are some examples and guidelines for writing effective user stories.
Using story points for estimation seems simple enough, but many teams fall back on old habits without realizing that they are misusing one of the key innovations of the Agile methodology. In the third installment of our series, we look at two more agile anti-patterns: conflating story points with story value, and relying on an anchor story.
A new book offers Agile-based principles and techniques for accelerating the innovation process, reducing inherent risks, and nurturing creativity and collaboration. Featuring 11 detailed case studies, it addresses five critical performance areas: strategy, portfolios, process, culture and infrastructure.
Story points are one of the most misunderstood and misused aspects of the Agile methodology. In the second installment of our series on Agile Anti-Patterns, we look at two more ways that story points can be used incorrectly, making the team both less agile and more frustrated in the process.
The Pomodoro Technique is a popular approach to time management, and it shares obvious similarities with some ubiquitous concepts in Agile, Lean and Scrum such as timeboxing and sprints. But is it really a good fit for teams working in Agile environments, or is it better employed as a personal productivity tool?
In this new series, we look at some common problems that Agile teams face, and the common “solutions” that rarely seem to work and often make things worse. Sometimes we need to avoid the well-worn path. Let’s start with the misguided attempt to directly translate story points to effort hours.
The most basic form of requirement in an Agile project is the User Story. It describes an actor, what the actor is trying to do, and the actor’s goals. Each story is unique, but they all should have the same components and adhere to the same guidelines. To make this happen, consider the acronym INVEST.