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.

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 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.

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

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.

Agile Requirements Definition and Management One of the myths of Agile software development is that documentation is not required or useful. It is true that one of the core values within the Agile Manifesto is "Working Software over Comprehensive Documentation." However, note the word "over" in this statement. The Manifesto is not saying no documentation; it's saying there is a preference for working software over documentation. If your organization is creating lengthy documents to produce software and you're still struggling to release software on time and within budget, then ask yourself this question: "What value are the documents adding?" The concept of Agile requirements definition and management (RDM) is not new. One theory relates to the complexity factor. If you're looking to adopt Agile and want to run a leaner operation, you have to take a holistic view of the organization. How it works — and doesn't work — in Scrum The most popular of the Agile frameworks in use is Scrum. Figure 1: Scrum/Sprint Agile RDM steps in

An introduction to personas and how to create them » Step Two Designs, Tina Calabria Written by Tina Calabria, published March 2nd, 2004 Categorised under: articles, intranets, usability & information architecture, websites Before embarking on any intranet or website design project, it is important to understand the needs of your users. There are many ways to identify the needs of users, such as usability testing, interviewing users, discussions with business stakeholders, and conducting surveys. This article explains what personas are, benefits of using personas, answers to common objections about personas, and practical steps towards creating them. Personas act as stand-ins for real users What are personas? Personas are archetypal users of an intranet or website that represent the needs of larger groups of users, in terms of their goals and personal characteristics. Personas identify the user motivations, expectations and goals responsible for driving online behaviour, and bring users to life by giving them names, personalities and often a photo. How to create personas

User Stories:Lack of Big Picture Leads to Blind Man Product One of the Scrum values is “Focus”. It can make or mar a product. It brings direction to the development of a product – from start to finish; and is the back-bone of an effective business strategy. Having said that, overdo it and the tables are turned. Here’s why: Analyse this picture. Tangled in their ‘focus’, they start thinking like what sight-less (blind) people are doing in this picture. If the blind man knew the big picture is Elephant, he would interprete the tail to be ‘tail’ and not ‘rope’. These are the different user stories that you see in the product backlog. The team never got a chance to grasp the overall goal or the big picture. Myopic view of the teamLack of visibility about the overall product itself – what are we making, why, for whom etcProduct owner himself is unaware of product vision and roadmapProduct owner is aware of the big picture but did not consider worth sharing with the team Have you faced such a blind man situation on your projects? Hello there!

What’s in a Story? « [This article has been translated into Korean by HongJoo Lee, French by Philippe Poumaroux, Spanish by Adrian Moya, Russian by Denis Oleynik, and German by Julia Kadauke.] Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria. Introduction Software delivery is about writing software to achieve business outcomes. Usually, the business outcomes are too coarse-grained to be used to directly write software (where do you start coding when the outcome is “save 5% of my operating costs”?) This, then, is the role of a Story. The structure of a story BDD provides a structure for a story. Telling the story The characteristics of a good story 1.