What Is an Agile User Story: Do You Need Them From Your Clients?

What Is an Agile User Story: Do You Need Them From Your Clients?
Page content

Although user stories were first utilized in software development to ensure the stakeholder or customer would get what they want, it is possible to use them on just about any Agile project.

Because the Agile Methodology uses iterations and sprints, user stories can aid project managers in deciphering quickly what “users” or stakeholders expect from the varying elements of a project.

User stories are brief and short, usually compiled on 3 x 5 inch cards; they are not meant to be lengthy or include long dialog. As Kelly Waters of Agile Software Development Made Easy states of user stories, they “should focus on the who, what, and why of a feature, not how.” The “how” is up to the project manager and assigned teams.

Say your client is a marketing firm. They might write a user story that says:

As a marketing firm, we want to be able to search for product use by demographic to analyze markets.

The who is the “marketing firm”; the what is the “ability to search for product use by demographic”; and the why is so they can “analyze markets.”

Based on your client’s user stories, you need to come up with the how. Of course the how represents your Agile project strategy to meet your client’s expectations.

Why Use Agile Stories?

The definition of Agile management is: “using the best process through empowered teams, customer involvement, and the ability to analyze and quickly control changes to the scope at inception and throughout the lifecycle of the project.” This statement alone should tell you why user stories are essential.

According to Agile Software Development, good user stories should have six elements or use the INVEST theory.

  • Independent – Don’t mix user stories together, each should be independent in and of itself.
  • Negotiable – Make sure your stakeholders understand that often user stories must be discussed based on elements and both you and the client may have to learn how to agree to disagree.
  • Valuable – If the user story is too vague, it won’t be helpful.
  • Estimable – User stories may have to be prioritized.
  • Small – Keep them short, user stories are not novels.
  • Testable – Make sure the user story actually offers something you can analyze or test.

During agile sprints, before the completed element of a project is passed to another team, user stories can help determine if the element was completed successfully or if it needs some alterations. Agile sprints are designed to complete tasks fast, usually within 30 days or less and client input is extremely important. Okaying an element without a customer user story may affect the entire project on a negative level.

Example

SBP Logo

For this example, let’s say your team is assigned to create a new business logo for a client. You are utilizing Agile Management and have teams designed to create logo ideas, design and actually produce the logo.

The first iteration assigned is to create the logo idea based on client input, which is absolutely necessary in Agile.

  1. Sprint team #1 creates the logo idea. Say you have a car dealer who needs a new business logo. Upon completion of the sprint logo ideas should be presented to the client based upon their user story. The user story might read: “I want a logo for my car dealership that will tell my customers I also perform auto body and paint repairs so I can gain more business.” The who, what and why are clearly stated in the user story so your sprint team needs to ensure they follow the direction of the user story before client approval and moving the logo idea to the design team.
  2. Sprint team #2 is handed the logo idea for design. They take the logo idea based on customer approval and design the logo. Say the approved logo idea is to create a logo that conveys the dealership’s company name and includes an auto body repair spray paint gun. This sprint teams runs with the idea based on an additional user story from the client. The client may write a story that says, “I want the name of my dealership to be the main element with the auto body and paint element secondary but still identified clearly so customers know I can help them with this service.” Sprint team #2 designs the logo to show “Sam’s Full Service Auto Sales” along with an auto body and paint spray gun with smaller wording below that says, “We Are Collision Repair Experts.” Again the client approves the outcome of this sprint and it is passed to the third team.
  3. Sprint team #3 who is responsible for the production of the logo will need yet a third user story from the client. The client may say, “I want the logo to be in these colors and also have the capability to be utilized not only on my company sign, but in formats available for print ads and advertising campaigns to mail to my customers.” Your third sprint team runs with that user story and completes the logo to the client’s satisfaction.

Coaching the User Story

Often, client involvement in creating the user story may be a challenge in itself. In the end though, it is worth the trouble. These contributions from clients and stakeholders ensure the sprints or iterations are passed along with customer acceptance and will be completed more timely and efficiently.