Skip to content

Category: user storySyndicate content

When is the story too big?

May 14, 2009 by Peter Stevens

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.

When should you advise your team not to accept a story because it is too big?

3 Warning Signs

Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:

  1. Past performance indicates you won’t get it done
  2. The story is large compared to the team capacity for the sprint
  3. The demo is complicated and / or demos many sub components.

What makes a good story

April 10, 2009 by Jack Milunsky

Introduction
Leading on from last week where I described that their are two main parts to user stories, the user (or persona or role) and the story (a short description of the intended functionality), this weeks blog is intended to focus on specific details on how to write good stories.

The three C's
Most of you are already aware of the 3 C's i believe originally conceived by Ron Jefferies - Card, Conversation and Confirmation.

Card
The card is important in that User Stories are meant to be written on Cards.






Why I don't use standard user story format that much

March 10, 2009 by Artem Marchenko

image Agile requirements are different from the traditional ones and are usually defined as user stories that allow for slicing functionality in the shippable increments. There are recommendations for a standard user story format and the most known one is “As a <type of user>, I want <some goal> so that <some reason>” popularized by Mike Cohn. The trend for recommending the common format is so strong that there is an evolution and there exist even hacks for making it work in the situations when it doesn’t fit naturally.

I used to be in the same camp of standard format proponents, until I noticed that more and more my stories look closer to “Implement list widget support” and further from “As an application designer I want to use a list widget so that…”.

Six features of a good user story - INVEST model renewed

November 5, 2008 by Artem Marchenko

"As a Product Owner and the development team we want to have user stories of the appropriate size so that we could plan realistically while not wasting time on estimating and managing what would anyway will be changed" - A possible user story.

User stories are the the most used format for agile requirements. The main point of the user stories is to focus on the concrete user needs and not on figuring out the extensive amount details that are known to be difficult to gather upfront. A usual recommendation for stories to make more sense is to follow the INVEST acronym popularized by Mike Cohn in his books on user stories and on estimating and planning . According to these books and various online recommendations a good user story should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

Filling the Product Backlog: Go For Excitement

October 1, 2008 by Peter Stevens


Picture courtesy of jakuza@Flickr

Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.

This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:

  1. Review the format of User Stories and the Kano Model.
  2. For each Role,
    1. Identify the main goals
    2. Identify the functions which that person wants the system to perform to achieve those goals
  3. Decide on next steps: Homework or Implementation

Creating the Scrum Product Backlog: Start with the Users!

September 24, 2008 by Peter Stevens

When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.

User Stories: Three Steps to Better Presentations

August 27, 2008 by Peter Stevens

Slide 'Waterfall' from Scrum Presentation

As a Scrum Coach, I often take on the role of Evangelist. Monday afternoon, I explained Scrum to the Swiss Java User Group[1]. Although not my first such talk, I had to completely rewrite the presentation. When this was 80% done, the realization hit me: How will I know if the "users" are getting what they need? Why am I not writing user stories?

Book Review: User Stories Applied

July 29, 2008 by JurgenAppelo

Userstoriesapplied The concept of writing user stories, as a way of documenting requirements, was introduced and popularized with Extreme Programming, and then picked up by Scrum and several other agile methods. Nowadays, for many agile developers, a project without user stories would be like a world without pizza. Impossible to imagine.

User Stories Applied
The book User Stories Applied, published in 2004 by Mike Cohn, is a landmark publication that has brought together everything the agile movement has learned about this important subject. Mike's book deals with all the activities that people have to perform when writing user stories, like techniques for requirements gathering, defining roles, working with user proxies, and preparing for acceptance testing. Mike also clearly explains how user stories can play a pivotal role in the wider agile project management processes of estimating, planning and monitoring.

Epics and Themes

May 6, 2008 by Artem Marchenko


User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of "As a [user role] I want to [goal], so that [reason]". Less people are acquainted with epics and themes usage.

Terms

Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be "As an environment conscious driver I want to be able to use both gas and hydrogene". A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.

XP Practice: Stories

December 5, 2007 by Artem Marchenko

Stories or User Stories is the XP practice of thinking about software in terms of units of customer-visible functionality. A canonical form of a user story looks like "As a <user-type> I want to a <goal> so that <reason>". For example, "As a Frequent Flier, I want to rebook a trip so that I save time when booking trips I take frequently" (from Mike Cohn's User Stories applied).

Best of AgileSoftwareDevelopment.com