• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Learn Business Analysis

Sponsored by BABLOCKS.COM

Learn Business Analysis
  • COURSES
  • MEMBERSHIP
  • RESOURCES
  • ABOUT US
  • LOGIN

User Stories Are Not Requirements

December 13, 2016 By Emal Bariali Leave a Comment

by Emal Bariali
December 13, 2016December 25, 2020Filed under:
  • Articles

I’ve seen many approaches to requirements & design over the years. Here is one that I’ve seen play out more than once:

  1. Design out the business processes.
  2. Generate a list of user stories.
  3. Hand them off the to the development team.
  4. Pat self on the back and walk away with a feeling of accomplishment.

“But wait a minute!” you’re thinking. “Is that all I have to do as a BA?”

The short answer is: No.

The long answer is a lot more useful. Bear with me here.

What Do The Developers See?

I always urge analysts to look at things from the developer’s point of view. When a developer receives something like this, they often see it as a list of unrelated items on a wishlist with very little thought put into the solution.

There is very little “systems thinking” in the requirements. Developers can’t build anything meaningful with this level of detail, and so they’re left to fend for themselves. They begin the painful process of poking and prodding the BA and the SME to tease out the details that they need.

“Its like pulling teeth” I’ve heard one developer say.

And when they’re not able to get the details they need, they resort to some pretty drastic measures to “be on time” with their deliverables. They start taking uneducated guesses of what the solution is supposed to be, and in doing so, they introduce a huge amount of risk into the project.

This increases project costs (the price of re-work); and in the worst of cases, it has the potential to bring down the entire project.

User Stories Are Just The Starting Point

I hold myself and my BA team members accountable for hitting 5 key points during requirements & design. User stories make up a small part of this framework:

  1. How does the business function?
  2. At what point in this process do users interact with the system?
  3. What are the business rules that the system has to enforce?
  4. What is the structure of the business data (business entities)?
  5. Are we clear about the life-cycle of the key business entities (how are they born? how do they live? when do they die?)

User stories fit into point #2.

If you’ve produced a list of user stories, chances are that you’ve answered point #1 in order to get the list. And if you’ve left your requirements off at just the list of user stories, then you’ve covered about 5% of point #2.

Your business stakeholders are happy because you’ve made their part of the solution relatively clear.

Your technical stakeholders? Well, let’s just say that they aren’t as enthusiastic about your work; and they have good reason to be concerned.

You Need To Provide More Detail

I sometimes get push-back from analysts when I insist that BAs are as responsible for the solution as they are for the requirements. BAs need to start thinking about the solution from the onset of the project. 

Not all the answers are going to be clear right up front, but “systems thinking” and solution thinking needs to be there as soon as the project is being conceived.

So What About Points #3, 4, and 5?

I’m going to talk about these in much more detail in future posts. The training program I’m building will also help BAs learn how to apply this entire framework to their requirements & design.

The Takeaways

  1. Recognize that your output as a BA has huge downstream impacts.
  2. Understand that meeting the needs of your downstream stakeholders (the dev team) are as important as meeting the needs of your upstream stakeholders (the business side).
  3. Learn what it takes to make sure your downstream stakeholders have what they need to build a solid solution.  A little bit of “systems thinking” will take you a long way to help meet the developer’s needs.

Post navigation

Previous Post Why Start-Ups Don't Hire Business Analysts
Next Post How Business Analysts Can Disagree With Their Managers (the right way)

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

BA Courses

Podcast Episodes

RSS BA BLOCKS for Business Analysts

  • 9: The 4 Ways ChatGPT and AI Will Change Business Analysis
  • 8: Customer Requirements for COTS vs. Custom Built Solutions
  • 7: How To Ace Your Next Business Analyst Interview (Part 1)
  • 6: Agile Myth vs. Agile Reality: An Interview With Dean Kulaweera
  • 5: What Do You Want From Your BA Career?
  • 4: The 3 Elements of Your BA Career Strategy
  • 3: Top 3 Sources of Skills for Business Analysts
  • 2: Top 3 Sources of Stress for Business Analysts
  • 1: How to Create a Fulfilling Business Analysis Career

Popular Articles

RSS Unknown Feed

Footer

FROM OUR COMMUNITY MEMBERS

RSS Members Only Simple Posts From BA BLOCKS

  • Hi Team, Here's the survey I was referring to in my previous post. I will send it by ...
  • Hi Everyone, The replay of the last lecture is available now. My apologies for the la...
  • Hi Team, Looking forward to seeing those who can make it tonight. We are nearing the ...
  • Great participation in the last Lecture - thank you all for having your video on; we'...
  • Office hours are still 6:00 PM ET. We had a small hiccup with the system due to day l...

PODCAST EPISODES

RSS BA BLOCKS for Business Analysts

  • 9: The 4 Ways ChatGPT and AI Will Change Business Analysis
  • 8: Customer Requirements for COTS vs. Custom Built Solutions
  • 7: How To Ace Your Next Business Analyst Interview (Part 1)
  • 6: Agile Myth vs. Agile Reality: An Interview With Dean Kulaweera
  • 5: What Do You Want From Your BA Career?
  • 4: The 3 Elements of Your BA Career Strategy
  • 3: Top 3 Sources of Skills for Business Analysts
  • 2: Top 3 Sources of Stress for Business Analysts
  • 1: How to Create a Fulfilling Business Analysis Career

THE BA DICTIONARY

RSS Business Analysis Terms and Definitions Archives – BABLOCKS.COM

  • Customer
  • Constraint
  • Agile
  • Technical Constraint
  • Business Constraint
  • Current State Analysis
  • Product Backlog
  • Minimum Viable Product
  • End-User
  • Business Analyst

Copyright © 2023 · Sponsored by