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.

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

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 Estimation Techniques One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article gives the details about user story estimation techniques that I've found effective. Powers of two Originally I estimated stories as one, two, three, four or as small, medium, large, extra-large. Use four values I was once on a project that started with 1, 2, 4, 8 as their estimation values. No averages or numbers not on the scale Four values allow you to get a rough estimate without spending unnecessary time focusing on precision. Vote independently It's human nature to be influenced by other people. Take the largest estimate Even when reminded, developers seem to have a hard time estimating with a team in mind. Taking the largest estimate has additional benefits. Finally, taking the largest estimate can help save time in an estimation meeting. Large estimate gaps Insufficient information Required involvement

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.

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!

Agile Software Development: Writing Good User Stories Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here: User Stories . User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front. As a guide for people writing User Stories, they can follow this basic construct: As a [user role], I want to [goal], so I can [reason]. This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why. As well as capturing User Stories in the above format on the Product Backlog , User Stories should be written on a card . The card comprises 3 parts: Card (i.e. the bit above, “as a user, I want…”) Conversation (notes and/or small wireframe to remind people about the feature) Confirmation (the tests that will show the feature is complete) Here’s an example User Story for you to take a look at. Ultimately, User Stories should be small. * Independent . * Negotiable .

User story History[edit] User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope "with user stories, which are like use cases". Rather than offered as a distinct practice, they were described as one of the "game pieces" used in the planning game. However, most of the further literature thrust around all the ways arguing that user stories are "unlike" use cases, in trying to answer in a more practical manner "how requirements are handled" in XP and more generally Agile projects. In 2001, Ron Jeffries proposed the well-known Three C's formula, i.e. A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction; The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally. Creating user stories[edit] Format[edit] "As a <role>, I want <goal/desire> so that <benefit>" Run tests Or

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