Stories

In Agile, stories are the business requirements for an application. You add a story for each feature that you would like to add to the application. In my experience, stories have 2 phases: 1) Initial and 2) Development Ready.

At the outset of the project, every system feature needed for the application should be defined as a Story and added to the Story Backlog, i.e. your list of features to be developed over the course of the project. At this Initial phase, stories require the following basics details:

• Short description – Brief description of who, what and why, e.g. "Prompt teachers to review test grades to ensure they entered the correct scores."
  
• Priority – This is the business priority, which can you can rate as High, Medium, Low, or 1-10, whatever works for you.
• Estimate – This is the development estimate. You can start with a High, Medium, Low estimate scale, although you may want to jump straight to a Dev Units estimate. Read this Story Estimates article, which outlines a straightforward means of converting raw estimates to Dev Units.
  

Most Agile projects use 3 x 5 cards, a project tracking system, a spreadsheet, or some combination. Click to see an example Story Backlog in spreadsheet format that was exported from a project tracking tool.

The basic version of the story created during the Initial phase is an Agile standard. One might add a paragraph description, but the story remains bare bones, not even close to your average use case, which is typically quite involved. I find this version of the story to only be adequate for a developer for the smallest of projects, such as 1 developer and 1 business person working side-by-side to further discuss requirements as they go. In most cases, the point of these initial skeleton stories is to enable scheduling.

Once you have defined the story priorities, you can plan your first milestone (Read more about Milestones). If you only have a few developers and have engaged business contacts working closely with development you are good to go. However, if you have a project with more than a few developers, you'll want them to be further refined so that they become Development Ready.

• Acceptance Criteria (AC) – List of requirements for a given story, such as descriptions of screens with fields to be included, description of validations, button functionality, etc. I find it very helpful for a QA engineer to be directly involved, either reviewing AC written by the business, or working with the business to write it themselves. At the end of the day, this should drive testing.
• UI Design – It is very helpful to have a design that includes the UI for a given story, or to provide a template for the developer to work from. Read more on the Case for UI Designers.
• Refined Estimates – Once the AC is complete and there is a UI design or a template to work from, developers should refine estimates.

Development Ready stories are still not nearly as heavy as your average use case, but provide the necessary detail for high quality development.