Skip to main content

Can projects do without Business Analysts?

My  last 2 gigs were a bit different to the usual ones from a team composition point of view. The bit that was different was that there weren't any Business Analysts on the team. My initial concerns were who would gather requirements? Who would analyse stories? Who would negotiate scope with the business? Who would be involved in Scope Management? Who would be our proxy customer?

The above questions got me concerned, but it wasn't as bad as i thought it to be. The customer was co-located with the team and we had easy access to validate our understanding on business rules, scope, sign-offs etc.

Our team composed of an IM, Devs and Testers. The IM was managing scope with the customer and getting the priorities. The team would then sit with the business to understand what the requirements were and we would create Epics and then further break them down into smaller chunks of workable stories. A thing to note here is that all roles would put their BA hat on and identify gaps if any while breaking down the stories. The business was open about design and the way the functionality would work and not crib about things, like specific error messages, or look and feel. A lot of that was left to the team to decide on what would work best for the product.

We would have shoulder checks with the testers and then at times also validate with the business if what we were building did meet their expectations or not. What could have been done better was to involve the business more often during shoulder checks in-order to further reduce the feedback loop.

In this case, the team themselves were proxy customers for themselves and would in a way validate on behalf of the business if what was being built was fit for purpose or not. As mentioned earlier, regular feedback from business helped keep us in check.

But, would this model work for all projects? Perhaps not. Gigs which require hardcore analysis require specialist BAs who focus on analysing the requirements. Building an Insurance portal which has so many business rules would require some detailed analysis which would require a dedicated role to just focus on ensuring the analysis is spot on. I totally believe in the value a Business Analyst would bring to the project. But it would be interesting to work on a project where the domain is complex, but there is no BA on the project.

Comments

Popular posts from this blog

How does one decide what to automate?

A question that has been troubling me for years is how much to automate. We all like to achieve maximum coverage and build a robust safety net where possible in order to give us confidence about the system under test. Given there is ample time i would like to automate almost everything, but in the real world, this isn't possible. This is when we introduced the concept of Value and Cost for a test scenario. Every test scenario would be assigned either of these attributes. Lets call the attribute automation classification High Value - Low Cost High Value - High Cost Low Value - Low Cost Low Value - High Cost What this translates into is we are associating business value and cost to automate to every scenario. So, when a test scenario is of high business value and the cost to automate it is low, then this becomes our ideal automation candidate. You would like to start automating all test scenarios that fit into the High Value - Low Cost category first. See picture below If tim...

Motivation of tester types

In my testing career span of close to 7 years, i have come across various testers. Every tester has unique skill sets and things that motivate them. Based on the various tasks a tester has to do on a daily basis or during a project, I would like to categorise these testers into 3 types Manual tester Automated tester Hybrid tester Manual testers are mainly non-technical and are focussed more on testing applications manually. These types of testers have good domain knowledge. Automated testers are technical testers who mainly deal with tools to help them test applications. They are given a set of test scenarios and all they need to do is automate these scenarios. Hybrid testers are like superman. They are expected to do whatever is thrown at them and it is these types of testers that are in demand these days. Now the interesting aspect is what motivates these testers in their day jobs. Lets take a look at this in the form of a graph where x-axis represents the various activit...

Test your services and not your UI

As a tester, i have spent more than 6 years trying to automate tests at the UI layer. As years passed, better automation frameworks evolved resulting in writing more manageable and maintainable code, but the only thing that wasn't getting better was the cost of maintaining these tests, especially when the no. of tests were 500+. There are multiple reasons why i feel creating an automated regression suite of tests at the UI layer is not good. Some of them are Limitations on what the tool can do Time taken to execute these tests leading to longer feedback loop Success rate of tests is not 100% due to latency issues Change in UI and UI flow resulting in an increase in cost to maintain UI tests On the other hand, testing business logic without having to deal with the dumb UI was a concept that a friend of mine at ThoughtWorks, Chirag Doshi introduced to me. He sent me couple of blog links written by Alex Verkhovsky about why is it so hard to do functional test automation at th...