Story Identification for Newbies

Event Modeling is Easy Story Identification Technique

For those new to Scrum, Story identification can seem intimidating. Even if you follow our guidelines in Chapter 3 – GSD Gold Approach to Story Writing, you may still have writer’s block. Event modeling is one of my favorite go to methods that get my Story writing juices flowing.

Every Story has a beginning, middle and ending. The Event kicks off the beginning of the process we want implemented, the Story Description outlines the what’s and why’s of the process, and the Acceptance Criteria instructs the reader how to tell if the Story has a happy or sad ending.

Simple.

It all starts with the Event.

Once you know the highest priority Epics and Component deliverables that must be implemented first, then brainstorm and list all the reasons why the Customer accesses the online portion of your application. Because I’ve previously written about the Customer Account Maintenance Component of an Online Banking app in my post Write Better Stories, I’ll use that same example, but approach Story identification from an Event Modeling perspective.

Here are just a few Customer Account Maintenance Online Events:

  • Customer receives Welcome Letter and wants to setup Online Access
  • Customer wants to setup Mobile Access
  • Customer wants to update personal information, such as physical addresses, email addresses, phone numbers, etc.
  • Customer cannot remember password
  • Customer wants to change password

Each one of these Events represents at least one Story that starts with “As an online banking customer, I want to…so that I can…”

Once you’ve exhausted all the Events that describe reasons why the Customer wants access the application, then brainstorm all back-end processes needed to support the online ones.

Some back-end Events could include:

  • New Customer application approval generates Welcome Letter to access new account
  • Customer account password expires
  • Customer incorrect password attempts triggers online account lock
  • By viewing the application from the Customer perspective, isn’t it easier to identify what Stories to write?

What tips and techniques do you use to get your Story writing juices flowing? Do share!

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

A Spike Story Should Get Story Points Too

Assigning Story Points to each Spike Story Improves Epic Planning Accuracy

In Scrum, we have a special type of Story called a Spike. The Product Owner or another team member writes a Spike Story when the team does not understand the requirement well enough to write a Story or architect a solution.

The Spike Story requirement describes what the team needs to learn or test before they can move forward with product development. Since all Stories must add value, the Spike acceptance criteria describes what must be completed or decided to provide closure. 

Example Spike use cases could include:

  • Install and become familiar with a new software tool.
  • Compare and analyze two similar architecture solutions in order to choose one to move forward with.
  • Research a long-standing issue or bug before designing a solution.

Why Write a Spike Story?

Scrum expects that the Development Team knows enough about the Story requirements to size the level of effort in Story Points to deliver the solution within the Sprint. When the team does not understand enough about how to develop the solution, the team acknowledges the fact and writes a Spike Story for the Backlog.

Use the power of the Spike sparingly. A Spike Story is not the same as Analysis and Design, which should be part of the lifecycle of every Story. A Spike Story has an outcome that allows the team to move forward with the real Story. In addition to the learning goal as acceptance criteria, another good practice is to add acceptance criteria that includes writing the successor Story and putting it in the Backlog as candidate for next Sprint.

Why Assign Story Points?

Most who practice Scrum do not assign Story Points to Spike Stories. We at GSD Mindset disagree. The output from a Spike Story is increased team knowledge that leads to better overall solution design. By assigning Story Points to a Spike, you also limit the level of effort expended to close it, so the team doesn’t get lost down some rat hole researching a new tool or attempting to resolve an issue.

It’s About Predictable Velocity for Planning

Energy expended to complete a Spike Story takes away from available energy spent to complete another Story from the Backlog. We at GSD Mindset believe everything brought into a Sprint should have Story Points, so you can better predict the total amount of work the team can complete within the Sprint.

Since Velocity is also used to estimate the length of time required to build an Epic, any background research or creation of small prototypes to try out potential solution architectures should be included in all planning estimates. Assigning Story Points to Spike Stories and including those points in the overall estimate for the Epic helps increase the accuracy of your team’s estimated time to completion.

What are your thoughts? Does your team size Spikes?

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Why Every Story should have Acceptance Criteria

Better Understand the Purpose of Story and Acceptance Criteria

Some who practice scrum believe that acceptance criteria are optional. Others only write a one sentence summary and don’t even bother writing story requirements. These practices could be a recipe for disaster, because developers may not understand what to develop and testers may not know what to test.

At GSD Mindset, we teach that acceptance criteria are mandatory, and we spend lots of time helping those new to scrum learn how to write stories. The story describes the requirement for that next slice of functionality the team needs to build. The acceptance criteria describe how the product owner and team know that the functionality works; they also describe what happens when something goes wrong.

If story content so profoundly impacts the team’s ability to produce quality work, then why do so many teams write crappy stories? We get that it takes time to think through and document the specific functional requirement, plus also to think through how to tell that the function works. We get it that most teams write their stories the night before or the morning of Story Grooming. We get it: your team is busy.

How much busier does the team become when stories take too long to close? How much busier does the team become after they build the wrong functionality and they have to rewrite it? How much busier does the team become when the project gets behind schedule?

After high level design and Epic breakdown, writing good stories is one of the most important activities the team performs. Taking the time to write a clear, concise story with clear, concise acceptance criteria can be one of the most important predictors of green project status and excellent quality.

How Do You Write a Good Story?

The Story format is simple:

As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>

When you sit down to write a story, think about who will be using the functionality, even if the user is another automated process. From the user perspective, visualize what function the user will be performing and why this slice of functionality is important.

For example, think about the customer of a shopping website. If the requirement is to build the first slice of a search tool, think about how the customer wants to search. Suppose research shows that most customers are brand conscious. Then write the first slice to search by brand:

As a customer of this shopping site,
I want to enter my favorite brand name
So I can see easily see all the products available for sale and quickly browse the list.

The requirement for this slice of functionality is clear. The reader understands what the customer wants to do and why: Because they came to the website with a specific brand in mind.

Yes, there are other ways customers search: by price or clothing type or gender, etc. But agile scrum stories only describe a slice of functionality. Every one of those other search parameters should be described in separate stories.

The acceptance criteria format is simple too:

Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>

How does the tester know that the brand search is working?

Given that the customer enters a brand name,
When the customer clicks to search,
Then the website returns the list of clothing in stock for that brand and displays a list that includes: small image, product name and price.

What does the website do if there is no clothing in stock for the brand?

Given that the customer enters a brand name,
When the customer clicks to search,
If there is nothing in stock for the brand, the website returns a message that includes the search parameter and offers the customer options to search for similar brands (e.g., people who search for A also search for B).

The effort to write a complete story that clearly describes required functionality and what to look for when testing does not really take much more time than writing a crappy, incomplete story. If your team is not writing stories complete with acceptance criteria, I urge you to try writing complete stories for at least 3 sprints.

I’ll bet you love the results!

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Write Better Stories

The 5 Key Ingredients to Write Better Stories

Every time we teach a GSD Scrum Training workshop, one of the most difficult concepts for students to grasp is how to write a story.
On the surface, the concept seems quite simple:

Describe the user’s functional requirement from their point of view and include acceptance criteria, so quality assurance testers know the finished product meets the user requirement.

The story and acceptance criteria format below looks simple enough, right?

Story format:
As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>

Acceptance criteria format:
Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>

Then, why do so many people have trouble writing stories? We think it’s because scrum assigns the Product Owner responsibility for writing the stories, and most Product Owners have never written functional requirements. That’s why we recommend scrum teams include a Business Analyst or Systems Analyst to work with and train the Product Owner.

Even if an analyst helps write the stories, a story is a very specific type of functional requirement. I like to compare it to a mini use case. The story begins with an event and follows a process through to a successful or unsuccessful outcome.

Well-written stories meet the following criteria:

  1. Stories deliver a completed slice of working functionality.
  2. Stories describe the user experience, not how to build it.
  3. Stories contain clear functional requirements and acceptance criteria.
  4. Stories are small enough to be completed within the time allotted to the sprint.
  5. Stories do not leave the application in an unstable state.

An example high-level use case would be Customer Account Maintenance. A good way to identify the stories that comprise this use case is to brainstorm all the reasons that a customer would access the application to execute this module.

Some candidate stories for Customer Account Maintenance:

  • Create a New Customer Account
  • Update Customer Account Information
  • Change Forgotten Password
  • Retrieve Forgotten Username

Each candidate story is a single slice of functionality that represents a small slice of the overall functional requirement. Each story requirement is small, so it can be completed within the sprint boundary. The team can start by implementing Create a New Customer Account, and then add the new functionality described in the other three stories at any time. That’s because each story can stand on its own and, if described correctly, will not leave the application in an unstable state.

Let’s write a story together. We want to be sure to clearly describe the user experience and quality assurance criteria. Although traditional scrum says that acceptance criteria are optional, we disagree. Everyone needs to understand both the requirement and how to tell if the product works as intended.

A well-written story for Update Customer Account Information:

 

Story:
As a customer
I want the ability to update the personal information on my account
So that I can keep the system up to date and continue to receive timely statements and product offers.

Acceptance criteria 1:
Given that I have previously logged into the system
When I access the personal information update page
Then I am able to update my first name, last name, address, phone number and email address

Acceptance criteria 2:
Given that I have updated my personal information
When I click Save
Then the system checks the validity and format of the data entered. If there are no issues with the entered data, the system updates the database. If there are issues with the data, the system displays an appropriate error message(s) and does not update the database.

The requirement is clear. Everyone understands what the customer wants to do and what information is considered personal account information. In addition, the application validates the customer entry, so invalid data does not get saved to the database to ensure data integrity.

The completed story for Update Customer Account Information meets all our criteria and, if it passes quality assurance, it could be moved to production at the end of the sprint.

Another thing to keep in mind is that the story’s requirements cannot depend on another team to perform work in order to close it. If a high-level use case contains functional requirements with dependencies across teams, the Product Owners of the affected team must clearly divide the experience into independent functional descriptions.

Once you understand the rules, the art of story writing becomes more straight-forward. Be sure to read and review each story at Story Grooming before sizing, so everyone on the team understands the requirement.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.

 

 

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more