Home Library Translate
A A A
Share »
Follow us on Facebook Follow us on Twitter Follow us on LinkedIn
Connect »

Blog: Business Communications

Menu

  • This Blog's Home
  • Guest Writer Submissions
  • Policies
  • To Subscribe to a Blog
  • About
  • Feedback

User Stories and Documentation

By Theresa Pojuner on January 23, 2013

I was reading about Agile and Scrum methodologies for project management when I came upon the term ‘User Story’. As an introduction, Agile is a methodology used for software development projects. It provides more control than just stepping through the analysis, design developing, testing, and implementing stages of a project as a whole. The Agile methodology breaks down each stage into subsets so that there is more communication, collaboration, feedback and discussion as each stage is completed. The Scrum methodology (a subset of Agile) is where each piece of a project is worked on as individual tasks for more accuracy and control.

A User Story (a further subset of the above methodologies) is a single sentence that describes a particular task that needs to be done. This need will define a particular project. As an example, suppose a manager is having trouble finding certain information on an employee. The manager may write the following sentence:  ‘as a manager, I would like to find employees with have not taken any sick days so that they can be given an award.’  That sentence or User Story is then brain-stormed to understand what the manager is requesting and to discuss details as to how to accomplish the task.  All subsequent ideas and solutions are noted and prioritized. The brain-storming sessions will also discuss items such as requirements, functionality, time, cost, tools, resources, due date, testing, etc., but not all in one meeting; each item is done separately and documented.

A User Story is not a Requirements Specification. The Requirements Specification is much more detailed and is basically an agreement which ensures that the client and the project managers are all on the same page. As a whole, it describes the project and outlines the client’s requirements and expectations up front.

In comparison, a User Story is brief and describes what the user wants in one sentence. If a User Story is long or needs to be broken down further (e.g., as a manager, I would like to find employees who have not taken any sick nor personal days so that they can be given an award), then it is known as an ‘epic’. The ‘epic’ will then be broken down into simpler sentences for clarity (e.g. as a manager, I would like to find employees who have not taken any sick days so that …. And   as a manager, I would like to find employees who have not taken any personal days so that …). In other words, a ‘to do list’ is created.  This list is known as a ‘product backlog’ and will be prioritized and managed by a product/project manager or technical writer. During various stages of the development, more User Stories (‘to do lists’) will be created either by the user, developer, or manager.

Are User Stories useful? Some say yes as it drives or communicates what a client wants and sets the stage for accomplishing individual tasks to complete a project, but others say that without the Requirements, Functional, or Technical Specifications, it is difficult to see how the finished product can be completed. No matter which methodologies are applied or what form of documentation is created, the written material should be able to explain in a concise and clear manner what was requested, how to accomplish it, and be focused on getting what the customer needs and that is what is important.

« Previous Next »

Search Our Site

Meet This Blog’s Host

Gail Zack Anderson, President of Applause, Inc., has nearly 20 years experience in training and coaching. She provides individual presentation coaching, and leads effective presentation workshops and effective trainer workshops. [Read more ...]


Theresa Pojuner is a Documentation Specialist with over 20 years of writing experience and is skilled in many areas of documentation, for example, Style Guides, Training Manuals and Test Cases, wth a specialty n Technical Writing and Procedures. [Read more ...]

Recent Blog Posts
Alternate Recent Posts Widget

  • Becoming A Technical Writer-Communicator Review
  • Creating A Knowledge Community
  • Tips for Handling Technical Writer Stress
  • Likeminded Communication
  • A Technical Writer Is Different From Other Writers
  • Involve and Engage Your Audience 20 Ways
  • Tips On Documenting Processes
  • Communicating Technical Writing Review
  • Communicating Via Visual Designs
  • Special Tips for Laptop Presentations

Related Library Topics

  • Body Language
  • Netiquette

Categories of Posts

  • Basics and Overviews
  • Body Language
  • Communicating Change
  • Communication Best Practices
  • Feedback (Sharing)
  • Humor in speaking
  • images
  • Listening
  • Netiquette
  • Presenting
  • slide shows
  • Speaking Skills
  • Team Presentations
  • technical writing
  • Telephone Skills
  • Uncategorized
  • Visual Aids
  • Voice and Vocal Habits
  • Writing

Library's Blogs

  • Boards of Directors
  • Building a Business
  • Business Communications
  • Business Ethics, Culture and Performance
  • Business Planning
  • Career Management
  • Coaching and Action Learning
  • Consulting and Organizational Development
  • Crisis Management
  • Customer Service
  • Facilitation
  • Free Management Library Blogs
  • Fundraising for Nonprofits
  • Human Resources
  • Leadership
  • Marketing and Social Media
  • Nonprofit Capacity Building
  • Project Management
  • Quality Management
  • Social Enterprise
  • Spirituality
  • Strategic Planning
  • Supervision
  • Team Building and Performance
  • Training and Development
About Feedback Legal Privacy Policy Contact Us
Free Management Library, © Copyright Authenticity Consulting, LLC ®; All rights reserved.
  • Graphics by Wylde Hare LLC
  • Website maintained by Caitlin Cahill

By continuing to use this site, you agree to our Privacy Policy.X