New to User Stories?Written for the Scrum Alliance. A CSP’s perspective on user stories, requirements, and use cases 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. Good requirements have the following characteristics: Complete. Traditional requirements focus on system operation. Use Cases A use case is a series of interactions by the user (Actor) with the system and the response of the system. Use cases focus on interactions and are written in such a way as to succinctly define the user/system activities and data that define the interaction. User Stories A good user story uses the “INVEST” model: Independent. User story–writing process Conclusion
The Easy Way to Writing Good User Stories Many development shops have opted to writing user stories over traditional feature/requirement documents; however, almost all of them struggle when writing their first batch of user stories. This is not at all uncommon, just like riding a bike, it does take a little bit of practice (but once you get it – you get it). Writing user stories is dead simple if you follow these simple steps: 1. When writing user stories, using this pattern is a for sure bullseye. As a account owner, I can check my balance online so that I can keep a daily balance 24 hours a day. Pretty easy right? As a account owner, I can check my balance online. Feel free to use slight deviations of this template using synonyms: As a [role], I want [feature] because [reason]As a [role], I can [feature]As a [role], I can [feature] so that [reason] 2. When creating new user stories, always hand write your new stories on a single side of a index card using a Sharpie marker. User stories are suppose to be short and sweet. P.S. 3.
User stories in VS2010 MSDN Library Design Tools Development Tools and Languages Mobile and Embedded Development Online Services patterns & practices Servers and Enterprise Development Web Development This topic has not yet been rated - Rate this topic User story (Agile) Other Versions This topic has been merged with its parent, Agile process template work item types and workflow. Did you find this helpful? Tell us more... (1500 characters remaining) Thank you for your feedback Show: © 2014 Microsoft.
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. 2. As you can see in Figure 1 user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios. Figure 1. Important considerations for writing user stories: Stakeholders write user stories. Figure 2. 2. Figure 3. 4. There are two areas where user stories affect the planning process on agile projects: Scheduling. Figure 4. 5. As you can see in the Disciplined Agile Delivery (DAD) life cycle of Figure 5, there are several distinct "phases" or seasons in the life cycle (some people will refer to the agile delivery life cycle as a release rhythm). Inception. Figure 5. Figure 6. 6. During JIT analysis/model storming with stakeholders. Figure 7. 7. 8. Translations Japanese
Use Cases or User Stories? Murali Krishna tells us: Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is. The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. Murali mirrors what many in the Agile community believe - that user stories are the only/best way to go and points us to an article by Mike Cohn, Advantages of User Stories for Requirements where Mike defines user stories: Each user story is composed of three aspects: Written description of the story, used for planning and as a reminder Conversations about the story that serve to flesh out the details of the story Tests that convey and document details that can be used to determine when a story is complete So it seems pretty clear that user stories are superior.
INVEST in Good Stories, and SMART Tasks | XP123 (French) In XP, we think of requirements of coming in the form of user stories. It would be easy to mistake the story card for the “whole story,” but Ron Jeffries points out that stories in XP have three components: Cards (their physical medium), Conversation (the discussion surrounding them), and Confirmation (tests that verify them). A pidgin language is a simplified language, usually used for trade, that allows people who can’t communicate in their native language to nonetheless work together. But what are characteristics of a good story? I – IndependentN – NegotiableV – ValuableE – EstimableS – SmallT – Testable Independent Stories are easiest to work with if they are independent. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.” Negotiable… and Negotiated A good story is negotiable. Valuable A story needs to be valuable. This is especially an issue when splitting stories. Estimable Small Testable
Where do User Stories Come From? Part 1. | Robert Galen An Approach for Generating User Stories I see many agile Product Owners struggle with backlogs on their own for new projects. Quite often they insist on personally owning the backlog-which equates to authoring every story themselves. While this approach certainly works, it does require a lot of additional vetting time with their teams-bringing them up to speed on the story content. So it can be time intensive and a bit wasteful. In his book User Stories Applied, author Mike Cohn discussed the notion of User Story Writing Workshops. I see way too much individualized story writing and too little group-based activity, so I wanted to spend some time in my next two posts discussing the dynamics and merits of User Story Writing Workshops. Getting a Facilitator One of the most critical success factors in the workshop is finding or declaring a facilitator. If you can't get someone who's independent, then go for facilitative experience. Workshop Logistics Brainstorm Roles First Wrapping-Up
Feature Injection and handling technical stories Technical stories don’t make sense As I learn more about stories and how they get written, I occasionally come across odd things that don’t make sense. One of these is the technical story. As a developer, I want an automated build So that I can be sure my code works. Of course, we’re resistant to letting developers have their own stories. As a business user, I want developers to have an automated build So that they can be sure their code works. This doesn’t make sense to me either. If there’s no benefit to the business, the chances are that a technical story isn’t really appropriate. As a business user I want the developers to refactor the UglyClass So that... um... Maybe not. Feature injection helps us talk about the business benefit There are some technical stories, though, which really do deliver something the business care about. This is where the feature injection comes in. In order to <deliver some business benefit> <these people> will need <these features>. Users aren’t stakeholders
The new user story backlog is a map Why the flat user story backlog doesn’t work, and how to build a better backlog that will help you more effectively explain your system, prioritize, and plan your releases. This is Gary. Gary and I worked together for a day to build a user story map - a better version of a product backlog. When it comes time to prioritize, Gary did so with the entire context of the system in view. Mimi shipped after a lot of sweat and effort from Gary, Dave Hoover, and the fine folks at Obtiva. Flat backlogs don't work for me One of the more troubling things, for me, about common Agile development practice is the idea of the flat user story backlog. I'm writing this from the plane as I fly back from a client site. Years later, I still love the approach… so much so that I'm in danger of seeing it as a "silver bullet" - which is an early warning sign that I'm becoming a dogmatic fool. Let me describe what's wrong with story writing, then generally what a story map is - and why it solves problems for me.
Splitting user stories: the hamburger method Problems: Story is too big to split and estimate; business users don’t accept any breakdown proposed by the delivery team; team is inexperienced and thinks about technical splitting only;new project starts and no simple starting stories can be foundSolution: User Story Hamburger I’ve evolved a new technique for splitting user stories over the last few months shamelessly stealing repurposing Jeff Patton’s User Story Mapping and ideas described by Craig Larman and Bas Vodde in Practices for Scaling Lean & Agile Development. I think it works particularly well in situations where a team cannot find a good way to break things down and is insisting on technical divisions. It has the visual playful aspect similar to innovation games and it’s easy to remember. Inexperienced teams often can’t get their heads around splitting stories into smaller stories that still deliver business value. Step 1: Identify tasks Step 2: Identify options for tasks Step 3: Combine results Step 4: Trim the hamburger
"As a Developer..." Is Not a User Story | Industrial Logic Look at these "user stories" I recently encountered: As a developer, I want to refactor the BarSplat module so that it has less duplication As a developer, I want to configure Jenkins so that we have continuous integration As a product owner, I want to have the stories estimated so that we can make a good plan As a tester, I want the test cases defined so I can test the system In Planning Extreme Programming, Kent Beck and Martin Fowler described a user story as "a chunk of functionality that is of value to the customer." Where is the customer value in those stories? Note: My argument is not that those activities are not good or important things to do (they are for this team), but that thinking of them as user stories misleads the team and its customers. Writing something in the form of a user story when it's not about users of the system misses the point. The Connextra Style of User Stories As a [role], I want to [do something] so that [reason/benefit] Where Do Poor Stories Come From?