For teams that are looking to agile to help improve their productivity, agile (which is not a methodology), has contained under its umbrella attractive methodologies to help teams improve their process.? One of the areas that can cause confusion and consternation is when your team defines requirements.? Let?s talk User Stories to see how we can build good stories to make great software.

Embracing Change Instead of Fearing It

All Agile methods embrace change rather than fearing it.? Traditional processes contend that introducing change late in the development process is costly.? Agile methods take a different approach.? They believe that software development is closer to product development.? Making critical decisions early in the decision is not optimal.? It is better to make decisions when we have a better understanding of this product, which happens later in the process.

[login]

?Welcome Changing Requirements, even late in development.? Agile processes harness change for the customer?s competitive advantage.?? This sums up the embrace of change.? To help allow teams do this, agile methods introduce User Stories and Minimum Marketable features to allow teams to change requirements, while keeping scope contained.

Agile planning gives business ways to change what the team is working on even near the end of the project.? Business owners can move stories or features near the end even if the stories are new. ?Of course stories that were originally planned need to be moved to a different time line when this happens.?

For this type of planning to work, both business and developers need to understand the requirements that are in the backlog.? Since User Stories are the main unit used for many agile teams, let?s focus on how to get user stories that are well written both technically and for the business owner.

Create Your backlog of User Stories

To get to good user stories, where should you start?? When beginning your project, creating an accurate backlog of user stories that captures the majority of features is essential.? To do that there is a technique that can be called sprint 0 or the inception workshop[1] that allows the team to create the backlog.

This initial way to create your backlog involves the team getting together in a room, for a week or two, without coding!? In a nutshell, the team can have user stories created, estimated along with some basic wireframes at the end of the sprint, so they know what product they must deliver.?

The team starts with a basic overview of the product.? They then create wireframes (on paper if that is easiest) of what the screens would look like.? Of course timing will vary on this, but as a rule of thumb, a lot a week or two for a project of the length of 3 months or less.?

The beauty of the inception meeting from a developer perspective is that your main backlog of user stories has been created and estimated in that one or two week timeframe.? Having both the stories written and estimated, allows the team to focus almost exclusively on producing the software once the next sprint starts.?

For the Inception Workshop to be successful, the stories need to be clear enough and succinct enough that both the developers and business owners understand the requirements.? This does not mean that the user story is a contract and the developer is bound to it.? Rather, the user story must help the developer and product owner have a conversation about the understanding of the story.? That conversation should result in more clarity between team members.

What Makes a Good User Story?

As stated above, the intent of the user story is to engender a conversation amongst team members.? By conversation, I also include wireframes, mockups and other artifacts that team members share.?

The accepted format for user stories, is to use the cadence, ?As a [type of user], I want [some action], ?so that [some reason]?.? ??The benefit of using this template is that it forces the writer to specify who is the story is for, and what needs to happen.? If you enforce the last part of the template, which some consider optional, the justification for the story is also given.? That can help the entire team understand the business reason for the story.

You can certainly try other formats.??? The user story template above was popularized by Mike Cohn, and is a standard, which may be helpful for your team, or perhaps not.? If you want to write stories in your own format, feel free, the idea is to get enough information packed on the front of a 3X5 card to get an intelligent conversation started on the story.?

Example User Story 1:

As a [Frequent Flyer], I want [to be able to easily view free flight redemption information from the standard reservation screen], so I [do not have to log into a different web site].

This story could be written without the use of the User Story Template.? It might look something like this:

Example User Story 2:

All frequent flyers should be able to log in to the standard web site and see what flights can be redeemed with my frequent flyer miles.? Frequent Flyer users should not have to log in to a separate site to see this.

The key for this story that should engender some conversation is that there is a user type of Frequent Flyer.? And there is a standard reservation screen, and another web site for frequent flyers.? The developers and business should be discussing the implications of taking these actions on an existing screen.?

This story should call for a quick mockup of the existing screen to show the developers where the redemption information should appear.? Developers will discuss how they will implement the new frequent flyer type of user.? Using the user story the team now knows what they are working on, and why.? But how does the team know when they are done with this user story?

Enter Acceptance Criteria

Acceptance Criteria seems like an easy topic to understand.? Write down what is expected in detail, so the team can understand what done is.? But how does this meet the idea of conversation over contracts??

Acceptance Criteria should help teams understand what done means.? There are many ways this can be accomplished.? Again the idea is for conversations to happen between business and the team.? So creating the AC should be done as an activity between the team members working on the story and business.? If there is a QA role, that role can be a great facilitator in helping put the AC together.

AC can be automated acceptance tests.? Many eXtreme Programming (XP) practitioners would argue that using an automated acceptance testing framework is the best way to ensure that the conversation for done has taken place.? There are different frameworks that can accomplish this.? Fitnesse, a wiki based on Fit, is one popular framework allows the acceptance criteria to be written in a table like fashion.? Behavior Driven Development or BDD frameworks like RSpec , Cucumber and SpecFlow can be used to hook up User Stories.

It is beneficial as more and more features are added to have automated acceptances tests as part of your acceptance criteria strategy.? For the above user story, the AC for let?s say a fitnesse story might look like this.

Figure 1 Example(Fitnesse test)

As shown above, the fitnesse test has columns for Logged In User, User Role, Origin, Destination, Date, Price and Frequent Flyer Points.? This test assumes we can determine the frequent flyer points with the following information: logged in User? the specified user role, the origin, destination, date of the flight, and the price.? This examples shows a one way price, and if the user role is FF (Frequent Flyer), the redeemable FF Points can be shown.

?This fitnesse test leaves how the frequent flyer points are displayed up to a different set of testing and AC.? It is concerned with just that in code, if the user role is frequent flyer, the points are available.? This test should get the team discussing the assumptions presented here.? Hey, the user role FF means frequent flyer!? Perhaps the develepors had already created a frequent flyer role, in a different way.? We would need to represent that in the test.

With the AC defined in a table that will be hooked up to code, it is easy to have discussions between software developers and business.? Assumptions can be challenged, going to some concrete requirements, rather than going against words that may change.

Creating Exceptional User Stories

In the end, creating exceptional user stories requires an eye towards generating discussion.? Those stories that can generate discussion, and create automated specifications are good candidates for exceptional stories.? Creating exceptional user stories is not the only key to help your team become a high performance agile team.? But it is a piece to the puzzle.