How do we know when a user story is “done“? Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.

Or let’s have a look at another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes this feature brings. Maybe a proper user manual or user training is needed in this case?

In this article, a simple, but very powerful technique which is called Definition of Done (DoD) is explained.

As mentioned in my previous article Three Myths About Data Science Debunked, sooner or later business analysts will be involved a project with a machine learning or AI component. While BAs don’t necessarily need to know how statistical models work, understanding how to interpret their results can give them a competitive advantage.

This article discusses three concepts that can help analysts add value to data science projects (future articles will cover additional ones). Cultivating skills in these areas will increase your ability to build cross-functional alignment between business and data science teams and prevent bad decisions based on flawed analyses.

What are the most common elicitation challenges? This is one of the most discussed topics from my business analysis training sessions. A business analyst extracts information in various forms, from various sources, and transforms those findings into requirements and design artifacts. Let’s take a look at some of the common challenges during the elicitation process and how to address them.

Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project

In all my years as a Consultant Business Analyst, having reached a level of proficiency, I have realised that being a business analyst is seldom about the hard skills. In fact, it is more about the soft skills and BAs who operate at that level are more impressive and effective in their job. Hard skills like documentation, requirements elicitation, process maps etc. are easily taught and acquired but the soft skills are developed with experience and the right attitude towards this role. Over time I feel the perception of the value of BAs has diluted and I blame those who have been superficial about performing this role. Those who think their role is just about the tangible artefacts like the business requirements document, process maps, business case, etc. Those who think they are here to deliver a project and nothing else. Those who think the BA’s job is to take orders and execute. But the fact is that the role of a BA is a lot more subtle than one thinks. There is a much broader aspect to this role, which is often forgotten, and we get caught in deliverables and artefacts.

Let’s look at some aspects of this role, which are common knowledge and broaden our perspective of that. When the mindset of the Business Analyst changes to the bigger picture and to the more delicate facets to this role, you perform much better as a business analyst and are a more reliable and thus a desirable professional for companies.