Over the past ten years, a number of Agile software development process “guidelines,” or best practices, have formed and are now becoming widely adopted.  Terms used to describe these best practices are sometimes new to developers, so I defined the practices that I believe provide the most value to a wide variety of development teams in order to create a highly functional, unified software development process.  I have by no means compiled a full list, but over the next few posts I will introduce you to some ideas that you may find worthy of further investigation.

Agile Software Development Process: User Stories

Consider the following requirement and sub-requirements.

• 3 Simplified Purchasing

• 3.1 Customer Identification
  • 3.1.1 A web “cookie” shall be used to uniquely identify visitors
  • 3.1.2 Each customer shall be associated with a cookie
  • 3.1.3 Cookies shall be stored in an RDBMS
• 3.2 Sale presentation
  • 3.2.1 Each item for sale shall have a button marked “buy” next to the item
  • 3.2.2 Selecting the “buy” action shall trigger an order placement action
• 3.3 Fulfillment
  • 3.3.1 By default, all orders shall use the on-file default shipping information
  • 3.3.2 If available, all orders will use the customer’s default payment method
  • 3.3.3 It shall be possible for the customer  to cancel any order for up to 4 hours after they place that order.

This set of requirements is for something called “simplified purchasing.”  Take a moment or two to consider how you would sum it up in a single plain-English sentence.

The requirements called “simplified purchasing” describe the user’s desire for “one-click purchasing.” In terms of a user story this would be phrased as “As a user I want one-click purchasing.” User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

A user story does not necessarily replace requirements documents or other documents. A common scenario is that the user story is the unifying high-level description for the work that needs to be done to make sure that everybody involved has a common understanding of the work, from customer to developer to tester to doc writer and back to the customer.

Agile Software Development Process: Cross Functional Teams

A cross functional team is a small group of people (7 + or – 2) that works together towards a common purpose, where time is primarily spent as part of the team, and, as a team, has all of the skills needed in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

Next best practices I will explore? Collocation and Unit Testing.