• 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

Business Analysts, Do You Talk to Your Developers?

January 18, 2017 By Emal Bariali Leave a Comment

by Emal Bariali
January 18, 2017December 25, 2020Filed under:
  • Articles
  • Uncategorized

How do you know when the requirements are done?

In my earlier article, I talked about the 5 key points I hit during the requirements & design process. But even within that framework, it can be hard to know what level of detail to go into for each of the five requirements areas.

The short answer is: There is no one-size-fits-all.

The longer answer, as always, is a lot more useful.

You’ve Got to Find the Sweet Spot

Getting the right level of detail in your requirements & specifications is more art than science. Don’t panic just yet though, you don’t have to be Vincent van Gogh to figure it out. There are some guidelines you can follow.
Ask 3 basic questions of yourself:

  1. How are my relationships with my developers?
  2. How are my BA / BSA skills?
  3. What constraints is my project up against?

How Are My Relationships With My Developers?

Don’t look at me like that, I’m serious. How are your relationships? Are you looping your dev team into conversations early on in the project, or do they find out about the work when you finally throw a printed copy of your 285-page spec over the cubical wall to them? If it’s the latter, then I know why your spec is 285 pages long. It’s because you don’t talk to your developers enough.

How you interact with your dev team has a huge impact on how much detail you have to put in your Req’s & Spec’s. Your requirements can be done much faster if you’ve built open communication and mutual trust.

Keeping Them Engaged Helps You Find the Sweet Spot.

When I’m asked to produce requirements & specs, one of the first things I do is to run things by the dev team. As soon as I have some idea of what the solution looks like, I find out who is going to be leading the development on it, and I tell them that I need 30 minutes of their time. 

Sometimes they’re too busy and don’t wanna hear it, but most of the time they’re happy to get filled in because they know it’ll make their lives easier down the line.

In the meeting, I walk them through what I think the solution is going to look like (at a high level) and encourage them to speak up if they have any objections. The Sr. developers in your company understand technical constraints better than anyone else. If they say something is not going to work, then I know that I need to go back to the drawing board to re-think parts of the proposed solution.

Throughout the requirements process, I keep asking them for their opinion on the things that I think may cause problems down the line. These conversations help me “feel-out” where the dev team needs the most details, and which parts of the solution they can put together on their own. By keeping the dev team engaged, I know exactly where to put most of my effort and where I can afford to skimp if I need to.

This is also how I judge whether my requirements and specs are done or not; I feel out the situation to see when the dev team is satisfied with the level of detail, then I move onto the next part of the scope.
Like is said; more art than science.

An Ounce of Prevention = A Pound of Cure

By the time I release the specs to the dev team, they already have a pretty good idea of what needs to be done. And my requirements are way more implementable than if I had just gone off on my own and drafted a gigantic document with no development input.

What’s even more beneficial is the fact that the developers have already vetted the requirements & specs themselves. This means that there will be far fewer questions for me when the dev team starts the build. An ounce of prevention just saved me a pound of cure.

Not All Developers Are Made the Same

Of course, not all bad relationships are your fault. You’ll always run into difficult people who don’t “work well with others”. In a future post, I’ll talk about the different “types” of developers you’ll run into, and things you can do to work well with them.

The Takeaway

  1. Working closely with the development team will give you the best indication of when your Requirements & Specs are “done”. Building good relationships with them will help you be more effective as a BA and will also make your life easier.
  2. Relationships are a two-way street and not all bad relationships are entirely your fault, but you should be doing everything in your power to cultivate good professional relationships with your development team. You’d be surprised at how much unnecessary documentation you can cut out of your deliverables when you talk with, and have trust in your developers. Same goes for QA.

Post navigation

Previous Post How Business Analysts Can Disagree With Their Managers (the right way)
Next Post The 3 Ingredients of Business Analysis Success

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 Guys, Greetings! Please suggest me the best source to prepare for CBAP Exam. Your ...
  • Looking so forward to this! 😊...
  • Hi Emal Bariali, I have recently joined the community and looking forward to substant...
  • I am posting this inquiry regarding the BA course enrollment coming up on the 23rd. I...

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