Skip to main content

What's in a User Story?

Being Agile: my occasional ramblings on Agile development & Extreme Programming

I constantly run into people who claim to be Agile but don't understand XP (extreme programming). And a lot of people fail to grasp the essence of XP because they get stuck on an XP principle that they find threatening - 'pair programming' and 'test driven development' are the usual suspects.

I'll focus on Pair Programming and TDD another day. Today I want to discuss the most important and fundamental aspect of XP - User Stories.

User Stories are like better, state-of-the-art Use-Cases - simpler and lending themselves to be scheduled individually.

Think of a User Story as a fine-grained Use-Case, leading to better estimation of effort, tracking of progress, and higher quality of implementation (fewer bugs due to requirements that are fine-grained, thorough and less ambiguous).

A User Story looks just like a bug would in a bug tracking system:
  • a one-line title summarizing the requirement that the user story encapsulates
  • a detailed description consisting of a bulleted list of acceptance criteria
  • a schedulable unit of work whose progress can be tracked
It is the schedulable nature of a User Story that gives it a huge advantage over any other form of requirement gathering, including Use Cases.

Next Time: How to schedule User Stories

Comments

Popular posts from this blog

Splitting User Stories vs. Rally's "split" feature (that has nothing to do with it!)

Agile tool Rally has a "split" feature it recommends to handle "unfinished work" in a Scrum Sprint: Manage Unfinished Work - Split user stories ( new link ) Below are my observations on the "Split" feature in Rally (followed by a few excellent articles on Splitting User Stories):   This "split" feature in Rally has numerous problems: 1. Nothing to do with Splitting User Stories It has nothing to do with "Splitting a User Story" which is an advanced but fairly well-understood field in Agile, and a tool for Product Managers to use in one of the two scenarios: The Product Manager does it before an Iteration commences (i.e. during backlog creation or release planning) to create User Stories by business value that are right-sized, i.e. they can be comfortably implemented inside an iteration; The Product Manager does it in Iteration Planning or in the middle of an Iteration to reduce scope by removing/simplifying accept

Agile Entrepreneurs Manifesto

The  Agile Manifesto  defines the 4 core Values that define "Agile":  " Individuals and interactions",  " Working software",  " Customer collaboration", and  " Responding to change" As I applied Agile requirements (user stories), engineering (XP), and process & project management (Scrum & Kanban) to my startups  (RideStation, and Agile Entrepreneurs)  starting from 2005 to now in 2018, I learned numerous lessons and shared them with my fellow entrepreneurs for the next dozen years. These lessons I have incorporated by "extending" the Agile Manifesto with two additional values pertaining to  Product (5th) and Startup/Business (6th)  -  that the services consultants who wrote it in 2001 probably didn't have to contend with as most (all?) of them were not founders of product startups:  "User Validation, Customer Traction, and Business Milestones" Agile Entrepreneurs Manifesto Us

Entrepreneur Committee - Advisory Board of SVASE

For whatever it is worth, I would like to announce to my millions of would-be readers that I have been invited to join the Entrepreneur Committee on the Board of Advisors to the Silicon Valley Association of Startup Entrepreneurs . And I have accepted. If you're a hi-tech entrepreneur, I would love to hear your suggestions on what I can do in my "official" capacity to make SVASE a better organization for startups.