User stories are used in agile software development to provide concise descriptions of desired system functionality. They are written from the perspective of the person who will use the functionality and they utilize the following structure:
“As a (list the type of user), I want to (identify the desired outcome) so that (identify the user’s intent).” An example would be “As an investor, I want to see the unit value of my mutual fund so that I can see if I am losing money.”
In addition to this structure, user stories include the acceptance criteria, which describe how we will know that the story is complete.
User stories are not system / functional requirements nor do they state all the work the programmer must complete in order to support the story. They are sometimes written on 3x5 cards in order to force the author to be concise. A user story merely provides a reference point for a future discussion between the user (or product owner) and the developer. This discussion will happen when the story is pulled from the backlog for development. Based on the discussion, the developer will clarify the acceptance criteria and identify the tasks to be performed to complete the story.
User stories are, by design, very simple and easy to understand. But they can be difficult to write well. Following are some of the user-story challenges I’ve observed over the years.
Challenge – Some software functionality is consumed by a system, not a person
New software often need to produce data files to feed other systems, particularly those of vendors or partners. Although it feels a bit awkward, the framework can still be used as shown in the following example:
“As a broker/dealer firm, I want to receive a standard XYZ file so that I can process the data into my application systems.” The discipline provided by the standard story template is helpful because is still focuses the conversation on the intended use of the file rather than the manner in which the file is to be created. Agile trainer Mike Cohn has a blog article on this topic at: http://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems.
Challenge – It’s just a story, don’t try to use it to boil the ocean
Over the years, users have developed a conditioned response to delays in software development. They have always waited a long time to get any response from the development team and they think this could be their last opportunity. So they try to define a user story that does EVERYTHING they can think of. Ironically, some prioritization schemes now assign greater value to shorter stories and the big, “boil the ocean” story may never make it to the top of the backlog and may, therefore, never get done. Furthermore, if the “boil the ocean” story DOES make it to the top of the backlog, the developer will break it into several separate but related stories, each of which can be finished in a given sprint (or iteration).
So, it is important to keep the stories simple and small, but sill valuable.
Challenge – Can’t see the forest for the trees
After the user or product owner masters the art of the small story, the backlog may become difficult to understand. A long list of user stories may be productive for software development, but that same list will cause eyes to glaze over. All of these small user stories need to be organized in a way that makes sense to stakeholders such as product managers, program managers, and sponsors. One helpful technique is story mapping, which involves laying out the intended workflow activities of the system, then aligning the stories under those workflow activities. The stories can be organized first into a set of stories to support the minimum requirements of workflow. The remaining stories can be organized into a plan for future releases.
Additionally, one can organize stories in a top-down manner. For example, the developers of the Scaled Agile Framework (SAFe) recommend a program-level backlog comprised of features, which can fit into releases, not just sprints. The features are decomposed into multiple stories. At the highest level, they recommend the use of “epics” which can be tracked in a portfolio-level backlog. Epics, as the name implies, are quite large and encompass multiple features. The idea is to provide an appropriate level of visibility into the planning process for each level of stakeholder: executive, program management, and team.
Taking it from here
User stories are a foundation for agile software development but they can be challenging to write well. Your initial efforts will feel awkward and frustrating and may miss the target, but your results will improve as you get more experience. Take a look at the additional resources below and get started on writing your own stories.
Additional Resources:
Mike Cohn, Mountain Goat Software, on user stories
www.mountaingoatsoftware.com/topics/user-stories
The Agile Alliance, on Story Mapping
www.guide.agilealliance.org/guide/storymap.html
The Scaled Agile Framework (SAFe)
www.scaledagileframework.com
The INVEST model for user stories
www.youtube.com/watch?v=L_NyCczp0Fk
Three C's Definition "Card, Conversation, Confirmation"
www.guide.agilealliance.org/guide/3C.html
Written by Ron Montgomery, Management Consultant & Owner, OnPoint, LLC Ron is certified as a Project Management Professional, Agile Certified Practitioner and Certified ScrumMaster with over 35 years of hands-on experience in business planning, software development, process improvement & deployment of software solutions. By partnering with clients to drive business value from technology projects, Ron assists clients with business planning, IT strategy, project and program management, vendor selection and team training/mentoring.
Did you find this article informative? Let us keep you up-to-date on all of our training articles. Please sign up for our newsletter today!
Here are some related articles you may be interested in:
Communication Essentials For Project Managers
Creating An Agile Culture: Top 3 Challenges Empowered Teams Face
Learn How Action Oriented Team Management Can Drive Timely Results.
Lessons Learned Templates & Guide: A Managers Toolkit for Continuous Improvement
Agile Methodology: A Creative Approach to Project Management
Agile Success Factors: The Product Owner Role
At ManagingAmericans.com we customize organizational tools that discover & unlock the true potential of individuals and organizations. Our focus is to align objectives, engage people & link strategy to execution. We support that effort with 30+ Expert Consultants providing exclusive management & leadership training & management consultancy services in one easy to use location.