Author: Michael Boris

The End is Near for Business Analysts in Agile!

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 I don’t miss them (well, maybe a little). Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to…you know…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 Scrum1 project, the customer (aka the “Business”) is a part of the team. They describe what they want the solution to do and, under the guidance and protection of the Scrum Master, the Business, Developers and Testers go back and forth discussing, defining and refining, until the entire team has a good idea what’s to be built. The developers run off and write code, the testers test it and the output is demonstrated for the business at the end of the Sprint2. The entire team (including the customer) review what was built and demonstrated, and accept, correct or redirect the next round of work…lather, rinse, repeat.