Although the job of the Business Analyst is as old as Agile itself, people’s understanding of the role is sometimes a bit fuzzy. Oftentimes, as a result, it’s the one team position that’s sacrificed when budgets get lean. Of course, that’s a mistake that almost never adds up, whether you’re talking cost savings or outcomes.

But even when the importance of a Business Analyst is recognized, their role — and therefore their priorities — can seem vague. That goes for not just the team and the client but for the Business Analyst (BA), too.

The truth of the matter is, even experienced Business Analysts occasionally need a little bit of a reminder about their role to keep them on track. Without occasionally getting back to basics and reflecting on the essential priorities of the BA role, it can be easy to slip into making mistakes.

Here are five of the most common mistakes made by people in the Business Analyst role — even if it’s a role they’ve played for many years.

1. Only Measuring Progress or Success by 1 Metric

As the BA, probably one of your biggest challenges is dealing with metrics. How do you measure success? How about progress? Keeping in mind that success and progress come in many forms, it’s important to remember that metrics do as well.

For example, it’s easy to focus solely on whether or not you’re producing “working software”. But you do that at the expense of leaving out other metrics. Is the project coming in on time? Are you producing technical debt on a product that’s for a long-term client? Are internal users’ needs satisfied, as well as customer needs? And finally, are you addressing each one of these three important components: needs, issues, and goals?

2. Allowing Wasteful Documentation to Happen

If there’s one function of the BA that most people never forget, it’s that of producing documentation. Everything must be documented — the more the better!

Although that familiar credo is true to a large extent, it’s also possible to overdo it. Documentation that’s wasteful will bog down progress and kill team efficiency.

So, what defines ‘wasteful’? One example would be if a team is small, co-located, and working on a project in a short time frame. When a team like this meets daily, they form a good collective project memory that eliminates at least some of the need for documentation.

Even when teams aren’t co-located or they’re large, there’s still a ‘working memory’ that can be leveraged. Every BA should be aware of the extent to which certain documentation isn’t absolutely necessary under these circumstances.

The added benefit of keeping that ‘working memory’ at the forefront is that you avoid the endless spin that occurs at meetings when teams forget what’s already been covered and ask repeat questions.

3. Neglecting the Role of ‘Facilitator’

For a product to be successful, lots of conversations need to take place every day. Ideally, those discussions take place with the stakeholders involved as often as necessary. The best outcomes always come as a result of regular sessions where everyone can reflect on progress, measure alignment with goals, and reassess goals, fine-tuning the team.

In other words, the culture of collaboration (including feedback and reflection) needs to be very healthy and strong. That never just happens by accident and it’s the BA’s job to facilitate all of it.

4.  Focusing on Output Rather Than Outcome

Speaking of outcome, it’s all too common (and all too easy) to become so hyper-focused on deliverables that you lose sight of what’s really important: outcome. Keep the team working to meet deadlines but keep all your other goals in mind, too

5. Forgetting About the ‘V’ in INVEST

While we’re on the subject of goals, here’s our last bit of advice. Complex software products are complex. They have to fulfill a wide range of goals, as set out in the initial stages of the development process. If the ‘Discovery’ Phase is thorough and exhaustive, the BA should uncover a number of different goals, including various types of user requirements as well as business needs.

Among all those initial discussions with stakeholders, the BA should be able to form a general sense of how important each goal is. Some will have more value to the customer than others. Before any projects can begin, the BA must determine which ones those are. Without knowing the relative value of each goal, it’s going to be impossible to prioritize the work.

If you’re creating user stories according to the INVEST model, this is the ‘V’ in INVEST.

Of course, we’re assuming here that the BA is making sure those stories get produced. They help at all stages, but especially during the criteria assessment. Failing to give proper attention to INVEST is a whole other mistake, which we’ve covered before in a previous post.

Prioritizing goals isn’t easy since not all goals come with just quantitative values. The qualitative value of a goal means its priority is relative to other goals. It’s the job of the BA to juggle all those relative values so that the team works on the right thing at the right time. Remember, it’s about creating value.

Conclusion

By no means is this exhaustive coverage of what it takes to be a great Business Analyst. We’re always learning and we hope you are too! Stay tuned for more posts like this.