User Story Examples and Counterexamples. People who share my background in traditional requirements analysis often have a hard time coming up with Product Backlog Items representing thin vertical slices of potentially-shippable product.
Here are some good and bad examples that people have found useful. User Stories may assume template form (see User Stories Applied by Mike Cohn): “As a [role] I can [function] so that [rationale].” or expressed as noun phrase: “Image clipboard” or a 1-2 sentence story (ideally a testable assertion): “Busy streets are highlighted on the map.” User stories, like all Product Backlog Items, should contain or clearly imply acceptance criteria (definition of “done”). Bill Wake has given us the INVEST mnemonic to help remember the characteristics of a well-formed user story: I – IndependentN – NegotiableV – ValuableE – EstimableS – SmallT – Testable What does this look like in practice? A bank customer can change his PIN. How do we know when we’re missing the mark? “Design brochure layout.” 5 Common Mistakes We Make Writing User Stories. Most of the issues with gathering requirements in agile software development and agile testing derive from issues with User Stories.
Somehow expressing requirements in such a simple form causes a lot of trouble to agile teams. Of course art of writing good User Stories is the most difficult for new teams starting with a new agile project or these, which freshly transformed development methods to agile software development methodologies. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration.
New to User Stories? Having coached traditional requirements, use cases, user stories, and agile development, I’ve fielded a lot of questions around the differences among the three major ways of specifying requirements, particularly by people migrating to user stories.
To set the record straight on requirements, use cases, and user stories, I will describe each methodology and then compare the three against each other. Traditional requirements Traditional requirements are criteria to which the system or business must adhere. They are usually created before the coding begins and are nearly always written as text. They often are thought of as constraints, conditions, or capabilities to which the system must conform. Good requirements have the following characteristics: Complete.
Traditional requirements focus on system operation. Introduction to User Stories. 1.
Introduction to User Stories A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts. 2. Use cases vs User stories in Agile/Scrum development. TL;DR – User stories aren’t use cases.
By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases. Are user stories the same as use cases? When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story. Looking around the web, there’s consensus that use cases and user stories are not interchangeable: My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act.
Use cases vs User stories in Agile/Scrum development. Reinventing Agile: From Value to Solutions. InShare5 This post is a synthesis of two posts I originally published on my other blog "unRelated".
One of the key foundations and most attractive principle of Agile or Lean methodologies is that "Everyone can help each other remain focused on the highest possible business value per unit of time". I am certainly a strong supporter of that principle. However, value is often difficult to assess, I would actually argue that it is easier to identify what has less or little value, but what we think as valuable can potentially lead to many false positive, or simply be "business-as-usual" and hide the broader structure of the solution. "User Stories" are the corner stone of identifying and delivering value: An argument can be made that the user story is the most important artifact in agile development, because it is the container that primarily carries the value stream to the user, and agile development is all about rapid value delivery.
Architecture - What is the best resource for learning Scrum. Scrum et al. Advantages of the "As a user, I want" user story template. In my user stories book and in all my training and conference sessions on user stories I advocate writing user stories in the form of: “As a <type of user>, I want <some goal> so that <some reason>.”
While I consider the so-that clause optional, I really like this template. At a conference, someone asked me why. Because I get that question fairly often, I want to give three reasons why here: Reason 1 Something significant and I'm tempted to say magical happens when requirements are put in the first person. Reason 2 Having a structure to the stories actually helps the product owner prioritize. Fix exception handing Let users make reservations Users want to see photos Show room size options … and so on, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is. Look here, and you'll see what I mean: Seriously take a look at the image above before continuing … I'll wait … Please, really look at it before reading further. Control Chaos - Control Chaos. Sit Down and Learn from the Master: The ScrumMaster's Responsibility to Educate.
When I took my first Certified ScrumMaster course, I was taught that one of the responsibilities of the ScrumMaster is to educate.
The role of educator is an increasingly important one, as we see more and more organizations adopting Scrum at the enterprise level. However, the role is often neglected by ScrumMasters as they become busy supporting their teams' goals of delivering value to their businesses. Most Agile implementations are led by the IT organization and are then spread to other parts of the enterprise as those groups work with IT. This is not the best way to initiate an organization's transition to Scrum (a complete Agile transition should include changes to an organization's hiring practices, compensation systems, spending habits, facilities, working environment, team composition, etc.), but it is still the most common approach that I've seen.