Culture determines how people behave. If you want to change behaviour, you have to look to changing the culture. This is the story of how we changed the culture of a team of business analysts.

We inherited this team; they worked in an organisation where the culture was pretty poor. People were uninterested in their work. They resented the time they spent at work; they cheated on timecards; they simply did not do any work whenever they thought they could get away with it. Naturally enough, performance and productivity were abysmal.

Software handovers between teams and individuals in any ecosystem can be a minefield, often threatening to disrupt continuity and harmony across teams and organizations. In most cases, handovers result in knowledge loss, which in turn leads to chaos and time wastage when a critical issue hits the system. As a business analyst (BA), you will invariably be a part of the process, both at a junior and senior level. It is better to be fully aware of the complexities and pitfalls associated with taking part in a handover. You’ll eventually be able to apply some best practices to navigate around it (some of mine i hope and some of yours based on your context and area of operation).

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.