background preloader

The Easy Way to Writing Good User Stories

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. Related:  User StoriesRequirements

Connecting the Dots Between Analysis and Design Most software teams seem to lump together the terms Analysis and Design into one pre-development phase. This is unfortunate because with enough effort in first determining what you wish to build (aka Analysis) it is possible to understand the domain enough not to need up front architecture (aka Design). I find this much like a children’s connect-the-dots puzzle. For example, if each user story (or requirement) is flushed out ahead of time, it might be possible to view and understand the entire domain without connecting any lines. Understandably, it may not be possible to completely comprehend the domain solely on user stories. Determining what needs to be built is the hardest part of development. This process, while simple, still takes a lot of maturity to accomplish. Do not fall prey to Analysis Paralysis; sometimes good enough has to be good enough.

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

User Story Example I recently described User Stories and the composition of a User Story Card – Card, Conversation and Confirmation. I’m not really sure if you would consider this user story example to be good, bad or indifferent – I guess it depends what you’re used to – but here is an example nevertheless! This is the front of the card. The Card section describes the user story. Note the feature (for a user to log in to a web site) is small, so the story can be fairly well described on a small card. Clearly it’s not as detailed as a traditional specification, but annotating a visual representation of a small feature at a time, makes it fairly self explanatory for team members. And I would certainly argue it’s more easily digestable than a lengthy specification, especially for business colleagues. Here is the back of the card: The back of the card outlines the test cases for this feature – how it’s going to be confirmed. Kelly. Home

5 Common Mistakes We Make Writing User Stories - Scrum Alliance 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. Lets take a look at the five most common mistakes people make writing User Stories. Introduction to User Stories User Story is a short description of customer’s need. The main purpose of using this tool is estimation of an effort needed to implement a new feature in software accordingly to the Definition of DONE for the team. 1. 2. 3. 4. 5.

Attending a Scrum master training course … an event that started some critical thinking at the back of my mind - Part 2/2 - Willy's Reflections Continued from Attending a Scrum master training course … an event that started some critical thinking at the back of my mind - Part 1/2 which summarised the why I was on this course, some of my objectives (questions, scrum smells, etc.) and introduced changes to the Visual Studio ALM Rangers Scrum Poster. Day 2 … today was a phenomenal day and thanks to Chris, we had a very interactive day … we subsequently ran short on time and had to rush through the “slides”, but then the consensus was that the interactive nature was far more valuable. Most of today was spent going through planning and retrospective activities, including multiple teams, which kick-started the critical thinking even more. I do not have final answers to my questions as yet, but have decided to invest energy in this topic and possibly work on a whitepaper with a title such as “Schizophrenic scrum guide to distributed and virtual teams”. Watch the space … :) Your opinions and comments are welcome to the above!

How to write meaningful User Stories - Subcide I’ve seen a lot of projects fail when by all accounts, they shouldn’t have. The reason for this nearly every time, was that the requirements gathering stage of a project was done poorly, or sometimes not at all. Sometimes this is driven by budget or deadline constraints, and sometimes it’s because the people responsible are just unaware of how to go about gathering requirements in a structured manner, and if you’re one of those people, or know one of those people, then please read on. Requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building. Requirements serve many purposes, but when you strip them down to their core, requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building. Because of this, they should be as easy to read and understand as possible, which things like functional specification documents usually aren’t.

5 Common User Story Mistakes by Roman Pichler Story Mania Some product owners and teams are so fond of user stories that everything is expressed as a story. This either results in some rather odd stories – stories that capture the user interface design, complex user interactions, and technical requirements; or these aspects are simply overlooked. Like any technique, user story writing has its strengths and limitations. I find stories particularly well suited to capture product functionality, and when applied properly, nonfunctional requirements. But user interface design and complex user interactions are better described by other techniques including design sketches, mock-ups, scenarios, and storyboards. User Incognito A user story tells a story about a user interacting with the product. Make sure that all your stories have a clear user or customer. Disastrous Details The devil is in the details: Some stories are too big and vague for the team to understand and implement. Story Handoff Criteria Crisis Learn More

Leonid Systems Introduction What’s agile? What are user stories? Agile is a set of development practices that emphasize structured, incremental, short cycle executions (usually two to six weeks each). The practice favors person-to-person communication and working software (or systems) over extensive documentation. If no one is writing detailed specifications and requirements, how does the development team know what to build and test? As a <user type> I want to <do something> so I can <derive a benefit>. “As a standard user, I want to see who just called me so that I can call them back.” Before you start writing stories, you should characterize your various audiences. What stories are you going to tell here? The stories we’ll review here are about Leonid’s customers’ customers- businesses that use cloud communications. How did Leonid create these stories? At Leonid, we’re constantly developing stories. How do we use these stories? Customer Product Design Customer Process Design Leonid Product Design End User