Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The End is Near!

DZone 's Guide to

The End is Near!

No Country for Old Analysts.

· Agile Zone ·
Free Resource

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 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 Agile1 project, 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 Sprint2. The team (including the customer) reviews what was built and demonstrated, and correct 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 said they want….GAAAA! I don’t want to speak ill of the customer, but what they want and what they should get 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 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 and prioritizing requirements, we just need a PO who understands what the business needs, can write those needs in a form the developers understand and prioritizes the work to be done. BA? PO? I’ll have to ask HR which one gets paid more.


  1. “Agile” comes in many flavors. Scrum, Kanban, Lean, SAFe…we’re talking about Scrum. Don’t lose sleep over it.
  2. A Sprint is the length of time for each iterative “Define – Build – Demo” cycle. A Sprint is typically 2 -4 weeks, but can be any length the team defines.
Topics:
requirements gathering ,product owner ,business analyst ,user stories ,developer traits ,agile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}