Writing Effective User Stories

As a user, I can express a business need in user story format to get the IT solution I need
3.9 (23 ratings) Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
488 students enrolled
$19
$20
5% off
Take This Course
  • Lectures 9
  • Length 1 hour
  • Skill Level All Levels
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 12/2014 English

Course Description

User Stories are a great method for expressing stakeholder requirements, whether your projects follow an Agile, Iterative, or a Waterfall methodology. This 1-hour video course presents two common user story structures to help you ensure that your user stories have all the required components and that they express the true business need as succinctly as possible. It offers five simple rules to ensure that your user stories are the best that they can be. That, in turn, will reduce the amount of time needed in user story elaboration and discussion with the development team.

What are the requirements?

  • No technical background required
  • Desire to define user requirements in a User Story format
  • Interest in the field of business analysis
  • No additional materials are required

What am I going to get from this course?

  • Translate business needs into well-structured User Stories
  • Write User Stories that express the what and avoid the how
  • Apply five simple rules for writing effective User Stories
  • Clarify assumptions in user stories by adding context
  • Identify and remove ambiguous and subjective terms and phrases in User Stories
  • Select the appropriate format for expressing User Stories for Agile Projects
  • Write stakeholder requirements in User Story format that solve business problems
  • Elaborate User Stories to identify measurable non-functional requirements

What is the target audience?

  • Product Owners
  • Product and Project Managers
  • Subject Matter Experts
  • Business Process Users
  • Business Process Managers
  • Line Managers
  • Business Analysts
  • Anyone wearing the BA hat!

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: User Stories Defined
02:04

Learn the content of this course and assess its value to you.

08:40

User Stories are a great method for expressing stakeholder requirements for an IT solution. The first lecture is a general overview of User Stories.

Learning Objectives

  • Understand Business, Stakeholder, Solution and Transition Requirements as identified by the IIBA(TM).
  • List the components of a User Story
  • Express Stakeholder Requirements in User Story format
  • Realize who should be writing User Stories
  • Recognize when to write use User Stories in the Software Development Life Cycle
  • Discuss User Story Elaboration to identify functional and non-functional requirements
Section 2: Rules for Writing Effective User Stories
06:05

The next 5 lectures unveil a series of five rules that will make your user stories more effective. If you apply these rules to your writing, over time they will become automatic allowing you to become more agile in producing them.

Given that, let's talk rules. Rule number 1, the focus of this lecture, addresses the sentence structure of a User Story. Well-structured User Stories express a single action to achieve a specific goal from the perspective of a single role. Trying to express too much in a User Story adds confusion and increases the amount of discussion needed for developers to understand what the story really means.

05:42

When writing user stories, stakeholders knowledgeable about the role should focus on the business result that the IT solution will enable while leaving technology decisions up to the developers. What can you as the author do to make your life and your developers’ lives easier? In a word, lots. Rule 2 in the series states, “An effective user story emphasizes ‘what’ should be done, not ‘how’ to do it.”

Questions answered in this chapter:

  • How can you make sure that your user story expresses the what and not the how?
  • Why is it important that you distinguish between what and how?
08:09

Good user stories are relevant to the project, unambiguous, and understandable to knowledge peers. As the author of User Stories, you need to focus on writing stories that the delivered solution will provide. Ensuring that your User Stories are relevant reduces the time wasted writing and elaborating unneeded User Stories.

Questions answered in this chapter:

  • How can you decide whether a potential user story is relevant?
  • Why is relevance important?
11:17

Ambiguity is communication's biggest threat. If your User Story contains ambiguous words or phrases, the solution may not be what you desire.

Questions answered in this chapter:

  • How can you ensure that your audience understands your user story as you intend it?
  • How does ambiguity affect the quality of the solution?
09:43

Non-functional requirements are your best weapon in the war against unsatisfactory performance in IT solutions. Whether you use User Stories or conventional requirements, non-functional requirements are king.

Questions answered in this chapter:

  • How do you express non-functional (quality) requirements?
  • What value do non-functional requirements add to your user stories?
Section 3: Summary
02:11

Thank you for buying this course. In this last lecture, we will summarize rules 1-5 in an an easy to use cheat sheet.

We hope you enjoyed the course and that the techniques will help you in your quest for high quality User Stories.

BONUS LECTURE: What To Do When You Are Done
Article

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Tom and Angela Hathaway, BA-EXPERTS: Business Analysis for Anyone Wearing the BA Hat

Tom has been in business analysis since long before it was called business analysis. He has over 30 years experience in the fields of information technology, methodologies, and business analysis. In his writings and lectures he strives for enlightening while entertaining. As a facilitator, he achieves results through inclusion and synergistic group-building. He has taught thousands of students business and systems analysis skills since the '80's and has facilitated hundreds of requirements discovery sessions under a variety of acronyms (JAD, ASAP, JADr, JRP, etc).

Angela and Tom Hathaway (previously Hathaway & Associates, Inc. and Requirements Solutions Group, LLC) founded BA-EXPERTS in 2011. As a team, Angela and Tom have trained, consulted, mentored and coached thousands of business analysts around the world for organizations from small businesses to Fortune 100. Hundreds of current and past customers include TIAA-CREF (Financial), Cathay Pacific (Airline), Manitoba Telecom Services (Telecommunications), Starwood Hotels and Resorts (Hospitality), government agencies, and a myriad of organizations spanning all sizes and industries. Our training, consulting, and mentoring efforts have saved our customers around the world millions and can help your organization improve its business analysis practices

Instructor Biography

Daniel Myers, Senior Instructor at BA-EXPERTS

Dan has been in Business Analysis since 1978. He has over 35 years of experience in the fields of information technology, methodologies, requirements engineering, and business analysis. He authored three business analysis methodologies, and ten workshops (2-5 days) focused on the business analysis discipline. With these tools he trained and consulted with over five-hundred medium-sized to Fortune 100 companies on five continents. He also developed an “ASAP” methodology that would later be known as JAD, (IBM’s name).

Some of his customers were LL Bean, Smuckers, and other retailers, Lilly, Merck and other pharmaceuticals, Air Canada, United Airlines, Cathay Pacific, Emirates and other airlines, BlueCross, Cigna, Vanguard and other insurers, 6 of 7 of the largest companies in the state of Maine, Anchorage Municipal (government, police, fire, public schools, etc.), US Army, and numerous other government agencies and companies.

Ready to start learning?
Take This Course