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
Agile Software Development: 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. User Stories are derived from XP ( Extreme Programming ), however they can just as easily be used for in any agile development methodology , or indeed in any home-grown development process. A User Story is a simple statement about what a user wants to do with a feature of the software, written from a user’s perspective. A User Story should not use technical jargon or state design goals. User Stories should be written in business language that is understandable to all. A User Story should focus on the who, what and why of a feature, . For example, on a job site, two high-level User Stories might be: As a job seeker, I want to search for a job, so I can advance my career. As a recruiter, I want to post a job vacancy, so I can find a new team member. As a , I want to , so I can (a) it gives clarity as to why a feauture is useful; Kelly.
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: Example of a User Story
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 .
