Skip to main content

Author: Shane Turner

Taking responsibility for the outcome

As a Junior Business Analyst who’s about to go into a meeting to report on why our latest deployment into production had so many bugs –

it made me think about all the missed opportunities and potential questions I could have asked myself to catch them sooner.

As a business analyst, it’s my job to brief the team on the features that need to be developed, and ensure they get the designs and documentation to ensure a smooth, (hopefully) bug-free implementation that can be thoroughly tested before release. So why did we have four bugs then?

Assume responsibility

Asking yourself these questions may help to pinpoint where the issue originated:

1. How often are change requests initiated (not due to a change in business requirements), within the project – due to incomplete or incorrect requirements?

2. How often are bugs added to the backlog, as a result of unclear or misunderstood requirements?


How often are the designs or documentation being updated to re-clarify the requirements which have been misunderstood by the developers?

How often are the testers missing potential test scenarios due to lack of knowledge of the scope of the work being implemented?

How often are additional backlog items and stories created due to lack of completeness within the specifications?

How often does the client point of missing aspects of features or stories which have made their way into the staging environment or production due to a poorly fleshed out requirements spec?

(Less) Consistency is key.

I found myself answering ‘frequently’ to too many of the above questions, which not only impacts the overall deadline of the project, but it also costs our clients a fair penny in project costs.

Striving to be a better BA does not mean perfection from day 1, but rather small improvements over time – and that means starting with an honest reflection of where you may be falling short.

Don’t fall into the blame game of, “Oh, but the developer should have thought of this scenario”, or “Oh the testers should have picked it up”. You created the spec, you were there for the grooming, and the planning – and had the opportunity to glance over the test cases before development began.  Take ownership of the outcome.

So where did I fall short this time? Even though my spec was well thought out AND I provided the testers with a list of test scenarios to consider, the one thing I didn’t do – was consider the scope of the system being impacted in the development -resulting in an entire segment of the system going untested.

Sometimes we’re so focused on the little details that we forget to take a step back and take in the bigger picture.