“The most powerful person in the world is the story teller.”
– Attributed to Steve Jobs, Co-founder Apple Inc.
Nearly three decades ago, I remember my father taking me to a tailor’s shop for a pair of shorts to be worn as a high-school uniform. The tailor measured and made notes, and then he finally asked if they are alright with me. I wanted the length to be shorter. Both my father and the tailor were surprised because they were already short. In my mind, however, I was thinking of another use for the shorts. Most days after school I’d rush off to cricket matches. With a shorter length, it would be easier for me to play. As my father inquired more, he understood that my requirements were two in this case. To satisfy me, the other stakeholders, my father and the tailor in this case, agreed with my request, and I got what I wanted.
The above example is a simple case of a pair of shorts with only three stakeholders. Now, imagine a software development project. The process is a complex one with many stakeholders involved over months, sometimes years. In this process, written requirements with written words are many times inadequate, sometimes even inaccurate, and most of the time said requirements don’t convey the real intent. Also, in software development, requirement change is the rule, rather than the exception. Hence, frozen requirements during the initial stages create a number of issues later on.
This is where user stories, or generically “stories,” come in. Stories in Agile Development replace requirements. Stories are brief descriptions for small pieces of work items. It’s an extension of the user story concept. A user story is a brief description of a deliverable value to the user, which typically happens at the end of an iteration. Not all stories provide value to the users, but they provide value to stakeholders. This distinction between story and user story is important to know. To remember easily, you can say:
User stories represent value to the users, whereas stories represent value to the stakeholders.
Three Cs of Stories
The 3Cs of stories are actually for user stories, but I’ve taken some liberty and extended the Cs to be applicable for stories as well. They are:
- Card: Represents the “intent of the story” on an index card, sticky note, or an electronic tool. This is the most visible part of the 3Cs, but not the most important. Rather, it is mainly for the purpose of representation. There is a sense of feel when you hold a set of index cards and write stories. The size of the card is small, and therefore, limits any premature suggestion about work items to be done. Like in my example, a story card gives you something tangible like a piece of cotton for a pair of shorts.
- Conversation: Represents “a promise for a conversation.” The conversation part is important to any story, because it allows for collaboration and further discussion. Conversations happens among the user or customer, product owner, team, and/or other stakeholders. Conversations result in knowing what the user or customer actually wants. As in the case of the shorts, a conversation between me and the other two stakeholders resulted in knowing exactly what was required.
- Confirmation: Provides the acceptance criteria for the story and ensures that the story is implemented correctly. It’s the verification part. Acceptance criteria are usually written on the back of the story card. The final length of my shorts was confirmed, and then, recorded by the tailor.
These 3Cs are represented in the figure below.
Representation of Stories
We now know that stories are written on a bunch of index cards or sticky notes. Specifically, while writing user stories, Agile practitioners use a form which provides units of value to the end user:
“As a <role>, I want <need>, so that <business value>.”
The form of the above statement in a user story and essentially covers three Ws:
- First part – As a <role> – Who needs it?
- Second part – I want <need> – What is needed?
- Third part – So that <business benefit or business value> – Why is it needed?
Let’s consider an example of a flight ticket reservation portal. In this case, a traveler is booking a flight ticket. When written in story form, it becomes:
In the above user story statement:
- Traveler = Role
- Choosing the travel date = Need
- Proper planning for itinerary = Benefit or Value
Earlier, I said stories represent small units of work items, but how about big work items? In a flight reservation portal, a work item would be the search functionality allowing a traveler to search for a flight. This leads to the concept of epics in Agile development.
Story Breakdown Structure
A search functionality can be a big work item considering the functionalities needed (search by flight number, travel date/time, carrier name etc.) Since this is a large user story, it’s known as epic. An epic is broken down into multiple user stories. The epic “a traveler can search for a flight” would be broken down as follows:
- As a traveler, I can search for the flight by flight number (separate stories for other attributes such as carrier name, date/time), so that I can find the right flight quickly.
- As a traveler, I can view detailed information about a flight matched by the search, so that I can decide whether to take the flight.
- As a traveler, I can search by the passenger name record (PNR) details, so that I can find the status of the flight.
Once have your stories, you break them down to tasks, which can be estimated in hours. This happens in the Iteration Planning meeting (or Sprint Planning meeting, if you are using Scrum). This breakdown is shown in the below figure:
An epic may take months to complete. It is bigger than a release. A story should be done within an iteration. It is likely that its duration will be calculated in days. A task is estimated in hours and—something that can be completed within a day or within a few days. To understand more on release and iteration, refer to the article, Agile Release Planning!
Stories in Backlog
As we write stories on index cards and group them together, we get the product backlog. The product backlog is basically a bunch of index cards. Stories in the product backlog are prioritized. The prioritization can happen based on many factors. Things such as value delivered, cost incurred, risk involved, knowledge gained etc. should be considered. The prioritization is done by the product owner. The highest value item is prioritized and put on top of the product backlog. The product backlog items (PBIs) are not only prioritized, but also estimated.
The high priority PBIs are fine-grained, whereas as the low priority items, towards the bottom of the backlog, are coarse grained. They are likely to remain in the form of epics until they move closer to the top. This is shown in the below figure.
Features and Stories
You would have seen in many places, including the previously linked article, that the product backlog actually contains a list of features of what the customer wants. This raises the question of how features translate to user stories? It’s actually features which are broken down into stories.
Let’s return to our flight reservation portal example. An important feature needed by a traveler is the “ability to print the boarding pass” or “ability to have the boarding pass online,” which when converted to story becomes:
- As a traveler, I can print the boarding pass online, so that I don’t do that at the airport.
- As a traveler, I can have an online boarding pass, so that I don’t have to do that at the airport.
Various Types of Stories
As earlier noted, not all stories give value to the end users. However, it is likely any project requires many such stories. There will be work items to improve the infrastructure, improve processes, find a response to a risk, etc. These may not be directly providing value to the end user or customer, but will be needed for the product that you are building.
At a high level, you can say there are two types of stories.
- User stories
- Supporting stories
Do note that these notations are not universal, but labels for convenience. Stories with such modifiers help with communication, too. Some practitioners label user stories as functional stories and supporting stories as enabler stories.
User Stories
User stories are the most popular type. So far, we have seen few examples of user stories Let’s see a few more considering our flight reservation portal.
- As a portal administrator, I can edit and delete logged in user’s access, so that I can ensure each logged in user follows the site guidelines.
- As a partner, I can login to the portal, so that I am aware of the latest offerings.
- As a portal visitor, I want to see new facilities clearly visible in the portal, so that I come back more often and inform others.
As you can see, in the above three cases, the roles have changed from the traveler. The users can be a portal administrator, a partner, or a portal visitor who needs to be aware of the latest offerings.
Supporting stories to these aspects don’t represent direct value to the end user, but represent value to the stakeholders, whether it be scrum master, product owner, team, project manager, other managers, and/or other stakeholders. The supporting stories can be functional or non-functional in nature. If they are non-functional, it’s a good practice to timebox such stories.
Spike Stories
Spike is an XP concept. If the developer or customer is unsure about a solution to a technical problem or estimation for a story, spike can be developed to answer these questions. A spike story is a user story included in an iteration plan that is being undertaken specifically to gain knowledge or an answer a question. Most spike stories are thrown away, such as the example below:
- Figure out how to estimate (i.e., the ways to estimate) this item.
Architecturally Significant Stories
These stories help in making architectural decisions. In this case, a thin slice of the entire system or application. A story is built to determine and validate the potential architecture of the system. A prototype with needed code can be used to validate the architecture. For example:
- Get a list of flights from SkyAir’s web system.
SkyAir’s website is a partner’s site, and this story is architecturally significant because your own portal has to interface with SkyAir’s web system.
Analysis Stories
Analysis stories, as the name suggests, provide details needed to develop other stories. For example, you have analysis stories to analyze on a risk, have process improvement, or to analyze on an impediment, which is proving to be time-consuming, such as:
- Review the suggestions made by our partners to find out if we can implement some of those suggestions.
Infrastructure Stories
Every development team uses a number of infrastructure related to coding, debugging, deployment, and configuration, among many others. Infrastructure stories are about adding, or improving, new infrastructure. An example is:
- Check if the latest version of Tomcat can be used for the web-server.
There can be other story-types such as coding stories (which produce only code) or environmental stories (which help in setting-up a development environment).
INVESTing in Stories
A useful acronym used in the story ecosystem is INVEST. It was introduced by Bill Wake to describe and write good user stories. Although originally, it’s used for user stories, many characteristics here can be applied to other story types.
The INVEST acronym is explained in the below table.
Exercise on Stories
Now that we understand various types of stories, I’d like to walk you through an exercise which may provide a better understanding of the content. In the below table, there is a set of stories. Can you identify which story type they are most likely to be?
Go ahead! Try to make a guess on your own, and then, check the answers below. If you want to read back to the listing of various types of stories, go for it.
Estimating Stories
At this stage, you might be wondering how stories are estimated. Remember, earlier in this article I said that stories are prioritized and estimated and that the highest priority stories are on top of the product backlog.
Agile teams estimate stories in story points. Story points are relative and have no connection to any particular unit of measure. Said another way, story points are unit-less. To have a detailed understanding how Agile teams do estimation with story points, refer to the article, Understanding Project Estimation in Agile Development.
Conclusion
There is something special about stories. Think back to your childhood days. We all remember stories far more quickly than documents or just plain written words. Stories in Agile development answer that need, as well. Tell compelling stories of what the software is capable of doing, and you will generate interest in the user’s mind. Communicate with exciting stories on how your software or product can bring value, and you’ll see customers, users, and other stakeholders drawn in and responding.
—
This article is dedicated to the memory of my father, late Harendra Nath Dash, who passed away on June 11, 2019. A great teacher and mentor, he had a unique ability to simplify complex concepts starting with stories. It’s an homage to his knowledge giving and wealth sharing, which transformed many lives.
--
This article was first published by MPUG.com on 16th July, 2019.
References
[1] ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash
[2] Exploring Scrum: The Fundamentals by Dan Rawsthorne, Doug Shimp
[3] I Want To Be An ACP: The Plain and Simple Way To Be A PMI-ACP, 2nd Edition, by Satya Narayan Dash
[4] User Stories Applied: For Agile Software Development by Mike Cohn
