The GSD Gold Approach to Story Writing
Awesome! Your team has identified the feature Epics it plans to deliver and has broken them down into smaller components. Plus you know what components you need to build for your first planned release. In this chapter, you’ll learn how these components are translated into Stories.
You are ready to start filling your Backlog with Stories. Filling your what with what? In agile scrum, your Backlog is the prioritized list of Epics and Stories that your team plans to build. A Story is a small piece of functionality that is described in terms of a user requirement and test criteria.
So, how do GSD Gold Teams get started?
- Select an agile project management tool
- Start thinking about slices not layers
- Prioritize your first release Epic components
- Write stories and build your first sprint backlog
Select an Agile Project Management Tool
Before we get into story writing, we need a short discussion on agile project management tools. Don’t even think about managing your backlog on spreadsheets! Forget about continuing to use sticky notes, unless you want to spend a bunch of time pulling together manual reports (see Chapters 7 and 10). These tools do it for you seamlessly. There are dozens of tools on the market, the most popular being Atlassian JIRA and VersionOne.
We suggest that you research the available hosted packages. To be honest, the top choices are all very similar. Spend an hour or two researching them and pick one. We’ve both successfully managed agile projects using multiple tools. The important features to look for include: Epic tracking, story tracking, sprint management, task management and basic reports like Burn Down charts. Make sure you can easily export your Epics and Stories to a comma delimited file or spreadsheet.
Don’t stress out about this. If you don’t like the tool you selected after you start using it, then export your data to a spreadsheet and try another tool. Again, we’re agile now, so if you do not like something, review and adjust.
After you’ve configured your agile project management tool, enter the feature Epics into the tool, so you can link your stories to them. It’s also a good idea to list your first release components as part of the Epic description.
Slices Not Layers
Before we get into the nitty gritty details of story writing etiquette, let’s work on getting you more into the agile mindset.
With traditional project management, you build an application in much the same way that you construct a layer cake. First, you decide what type of cake you are going to bake by setting project scope. Then, you gather all the requirements, which are the ingredients. You design your application based on the requirements and lay down the infrastructure to begin coding. Next, you code on top of the infrastructure. When you are finished coding, you test. Then, you allow the stakeholders access and add any final layers or icing before moving to production. Every aspect of the project builds on the prior aspect.
In today’s fast-paced business economy, we can’t afford to wait for all requirements to be known to start building our application. We can’t afford to wait until all development is complete and tested before we demo to our stakeholders and let them play with the application. We need a way to deliver at the speed of business.
Throw out the traditional waterfall paradigm! Begin thinking about building complete working slices of code, not fully baked layers.
Here’s what we’re talking about: Let’s say, as part of your project, your team has to build data services that provide external systems access to your new application data. Let’s also say that service architecture is a new concept for your team, so it is high priority and on the critical path. How can you get stuff done quickly and reduce risk?
Build a small slice of your data service in the very first sprint. Write a story to build a small service with a simple contract, where you pass an ID and receive back a text description. Implementing that simple story requires setting up the service architecture, either on premise or in the cloud, passing a service request and returning a response. At the completion of this story, you will have the initial kinks worked out of your service architecture and a working service that you could move to production.
Suppose that by the end of the first sprint, while the programmers were coding, your Business Analyst and Product Owner finished negotiating the service contract. Next sprint, you can add a Story to stub the complete service. So, after 2 sprints, your data consumers can try consuming the stub.
See how each sprint you deliver added functionality until you are ready to hook it into the live application?
Stop waiting until you have all the answers to begin coding the critical pieces of your application. You now have an agile mindset. Start with the little bit you know today. Design it, code it, test it, demo it and, most importantly, let your stakeholders use it. Then add another slice.
The GSD Gold Approach to Identifying Stories
In GSD, we go through the following steps to identify Stories for our Backlog:
- Prioritize first release Epic components
- Write Stories for high priority components
- Decide if need to conduct research or Spikes
Prioritize Your First Release Epic Components
You know the components that comprise your MVP first release. Meet with your Product Owner to verify priority.Update the first release component list to reflect this priority as well as the Epic Descriptions in your project management tool.
Review the prioritized Epics and components list with the team to get a good idea about how many high-priority components you can build in the first 2 week sprint. Now, you are ready to write Stories and build your Backlog.
Write Stories and Build the Backlog
In agile scrum, a Story is a short, simple description of a feature component told from the perspective of the person or user role who needs it. Always remember that a story is a functional requirement that describe what the user wants; it is not a programming specification that describes how the programmer should develop it.
In traditional agile scrum, the Product Owner is the one who writes the stories for the Backlog, because that role represents the business stakeholders. In real life, most Product Owners do not understand enough about application development to write good user stories. We at GSD recommend having a Business Analyst on the team to work with the Product Owner and break down the components into user Stories.
A user Story has two parts: the user requirement and the acceptance criteria for quality assurance. Some agile practitioners say that acceptance criteria are optional. That’s BS. Everyone needs to understand both the requirement and how to tell that the application works as intended or else how do you know you delivered what was committed to?
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>
Example story:
Title: Customer updates personal 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.
This example Story describes the requirement for a single aspect of a customer’s personal data entry. If there are multiple aspects, then multiple stories should be written.
Two things to keep in mind when writing user Stories:
- Stories perform a single function.
- Stories are small enough to be completed within the time allotted to the sprint. If you think the Story is too big to complete within the sprint boundary, break it down into a smaller piece of functionality.
Completed Stories must be ready to move to production. Stories should not be so small that if moved to production, they would leave the application in an unstable state. For example, you would not implement a search feature without including the search results list.
Spikes
There is a special type of Story called a Spike. A Spike is used when the team does not understand the requirement enough to write a Story and/or code a solution.
A couple example use cases for writing a Spike:
Install and become familiar with a new software tool
Research an issue or bug before designing a solution
The acceptance criteria for a Spike becomes the learning goal for the programmer(s) who pick up the Story.
Do Product Owners and Business Analysts Write Stories for Their Work?
The quick is answer is No. The Product Owner and Business Analyst gather requirements and write the stories, so they do not need a story to write the story and build the backlog.
The GSD Gold Standard for Excellent Stories
Stories must be written so all requirements can be developed, tested and closed by the team that picks it up at sprint planning.
What does this mean? This means that an individual Story’s user requirements and acceptance criteria cannot depend on members of any other team to perform work in order to close the Story.
How can you implement application dependencies across teams and other functional areas? Individual Stories can be dependent on other Stories, even Stories to be completed by another team. Coordination and timing are key. Agile scrum even has a special meeting called the Scrum of Scrums to help with this. We discuss Scrum of Scrums in Chapter 6 on Sprinting.
For now, as you write your first Stories, we want you to keep in mind that the concept of self-managing teams extends to Story writing too.
< Back to Chapter 2 Project Planning —– Chapter 4 Story Grooming >
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.