Every Business Analyst (BA) knows there’s a minefield of mistakes to be made on any given day. Many are self-inflicted and can be anticipated and prevented. Here are six examples of common mistakes that all successful BAs must take into account.
1. Leaving Out Key Stakeholders
The requirements-gathering phase shouldn’t be completed solely by the Business Analyst alone. Ideally, the requirements review should be done with the proper involvement of key stakeholders to validate the importance of requirements against different perspectives.
Typical team roles include:
- Product Owner
- Business Analyst
- Project Manager
- Tech Lead
- UX Designer
- Quality Assurance Analyst
Measuring the collected requirements against the related attributes with concerned stakeholders helps minimize any possible defects before the development stage begins.
2. Failing to Prevent Scope Creep
Scope creep occurs when the scope of a project changes uncontrollably. This usually has an adverse impact and usually, the client is not willing to assume additional costs or extend the time.
But how can a BA prevent scope creep?
- Comprehension. First, take steps to make sure you understand scope of your project. Get a true sense of the real business need, the high-level goals, and the business objectives.
- Documentation. Secondly, document requirements exhaustively. While documenting explicit requirements can be easy, gathering implicit requirements are tough nuts to crack.
- Education. Then, educate the client. a BA could educate the client not to rush during the requirements gathering stage and, therefore, make the client aware of the dangers of uncontrolled scope changes.
- More Documentation. Trace the Requirements: completing an effective Requirements Traceability process helps in identifying those features / functionalities that are of value.
3. Not INVESTing
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort for implementation.
Sometimes, Business Analysts do not properly embrace the INVEST model. In order to create good user stories, start by remembering to INVEST. INVEST is an acronym which encompasses the following concepts which make up a good user story:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
4. Going Beyond the Level of Detail Required
Not everything needs to be known before a story is started.
Alright, but how about questions the Development Team may have? Questions should come up while the team is working on a story. As BAs, we want to avoid thinking of everything upfront, adding too much detail to a story. That invariably ends with functionality that takes far too long to make it into the hands of users. It can also lead to longer time-to-market as team members are stalled waiting for answers.
It’s really an act of balance. If we put a user story into an iteration before it is understood well enough, we will have too many open problems, which create obstacles to completion. On the contrary, if you try to solve each open problem and add even the smallest detail to a story, you will end up with a functionality that takes too long to reach users.
5. Requirements Prematurely Deemed 100% Complete
Some Business Analysts feel that the documented requirements are 100% correct even before sharing with stakeholders. The less experienced business analysts have a common notion that any corrections they make in the documented requirements mean that they didn’t do the job correctly.
However, there are no fixed parameters for the BA’s evaluation that stop them from changing the requirements once they’ve been documented.
6. Managing Assumptions Badly
Assumptions are an integral part of gathering requirements and can make a good project or ruin it. In general, adding many assumptions makes the user stories very diffuse and their scope not sufficiently clear.
In general, we should try to avoid assuming too much. Do this by applying effective requirements-gathering techniques at the early stages of the software discovery phase.
As a practice, always compare assumptions with actual results and critically assess how these assumptions might have been better.
—
As Niels Bohr once said: “An expert is a person who has made all the mistakes that can be made in a very narrow field.” For sure that during your career you will go through all these mistakes, and more, maybe.
But, if you can avoid these six common mistakes, you’ll find yourself in the small group of Business Analysts who aren’t successful just once, but successful over and over again, delivering an excellent analysis of your project.