The Community Blog for Business Analysts


The End is Near!

I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-thick formal requirements document.  I’ve written them, and to be honest, I don’t miss them. Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to…well…be agile.  Direction, goals, deliverables and requirements could be adjusted, redirected or scrapped altogether every few weeks.  “Wait a minute Mike, I just heard you say the ‘R’ word, as in... ‘Requirements’”.  Yes, I did…and it wasn’t a mistake.  With very few exceptions, every project needs requirements. You need to know what the project is supposed to deliver, why there is a team and a budget…and why the project has some catchy name (typically in the form of a questionable acronym). 

Here how it’s supposed to work (feel free to skip ahead if this isn’t your first Agile Rodeo): In a fully adopted Agile project (I know “Agile” comes in many flavors.  Scrum, Kanban, Lean, SAFe…I’m talking about Scrum. Don’t get all worked up about it.), the customer (aka the “business”) is a part of the team.  They speak directly to the developers and describe what they want the solution to do. The business and the developers go back and forth discussing, defining and refining, until the developer has a pretty good idea what to build. The developer runs off and writes code, tests it and demonstrates it to the business at the end of the Sprint. The team (including the customer) review what was built and demonstrated, and accept or redirect the next round of work…lather, rinse, repeat.

I have spent a good bit of my career keeping the business away from the developers.  Developers are great people. They have fantastic skills, deep understanding of their trade and they really, really want to help.  In fact a developer will deliver exactly what the customer says they want….GAAAA!  I don’t want to speak ill of the customer, but what they want and what they need are not always the same thing.  As a BA it’s my job to understand what the business does, needs and should or shouldn’t have…and to translate that into something the developer understands. There is often a lot of pushback and justification…a lot of wailing and gnashing of teeth. 

Enter the Agile Product Owner.  While a BA, in the classic sense, is not on the list of Agile Team Members, there is still a need to bridge the gap between customers and overly-helpful developers.  An Agile Product Owner has an understanding of what the final deliverable product should be (remember, it’s not the job of the BA, customer or Product Owner to define HOW functionality should be delivered, just WHAT the deliverables are) and prioritizes the work accordingly. 
So, no, we don’t need a BA on our Agile Team.  Instead of a BA going out to define current state and understand the future state business needs, writing those need in a form the developers understand and prioritizes them, we just need a PO who understands what the business needs, can write those needs in a form the developers understand and prioritizes them…hmmmm.  BA? PO?  I’ll have to ask HR which one pays better.

Mike is a Principal Consultant and the Business Strategy Technology Lead at Moser Consulting. With a degree in Ceramic Engineering from Rutgers University, Mike’s career has been focused almost exclusively on process design and improvement. He started with process and materials design for aerospace coatings in the late ‘80s, and made the switch to IT after saving the company from the sure destruction of Y2K. Over his 30+ year career Mike has had the pleasure of digging into processes in regulated pharma, manufacturing, field service, government, insurance, airlines, marketing, and utilities, among others, and would love to experience more. Drop him a line on LinkedIn ( or at [email protected]

This entry was published on Jul 27, 2022 / TheBori. Posted in Roles and Responsibilities. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  2 members liked this article

Related Articles


Benjamen Walsh posted on Monday, November 14, 2022 10:02 PM
Hi Mike,

Ben here. GM of Value and Innovation from Assurity Consulting who runs a team of 30+ consultant BAs.

I really like the first half of your article and the definition of what an Agile product owner should do but I disagree that the PO replaces the BA in the future. To get this on the table first - No I don't believe the BA is just a great requirements writer who works for the PO which is a sad state that some BAs find themselves in within a fully agile delivery environment (and I don't think you were suggesting this model either). So to partly agree with you. within an agile delivery team, the BA role is mostly not needed (if PO can write requirements).

Then the question then falls to what is the purpose of a BA and where they add the most value.
BAs need to move back to their traditional focus which was on the Business, not products. The main skill of a BA is process modelling applied to a business model to work out where innovation can be unlocked, where value is at risk or value capture can be improved. Therefore Bas's job starts well before the project and product lifecycles. They work out if a desirable idea is viable and feasible to explore via a business case (with clear problem definitions), they identify where the pain points are within the internal process hierarchy and/or external customer touch points, and they then take their business cases (and tested) solution hypothesis and help shape the highest level requirements of a solution. This is then tested during the product management/lean start-up phase BEFORE entering the Agile Delivery process.

BAs can add a huge amount of value if used on business processes and problems and yes their most valuable place is not within the Agile delivery team.
Benjamen Walsh
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC