Moving on, we will investigate the importance of the business analyst’s often delicate relationship with individual stakeholders.   A business analyst is a facilitator of change, and in affecting these changes within a company, the analyst must interact with multiple stakeholders of varying personalities. When identifying and delivering the necessary changes within a business, the analyst must develop and maintain a relationship with each individual stakeholder.  Each stakeholder will wield a different level of authority within the company and hold a certain amount of power over those changes that are coming into effect. Noting this, the analyst must take part in a careful balancing act, juggling these relationships in order to facilitate change with minimal difficulty.

This short paper series, “Deep Dive Models in Agile”, provides valuable information for the Product Owner community to use additional good practices in their projects. In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

The Business Model Canvas is a common method to build a business plan in very large and small companies because it is both structured and very simple to understand. The Business Model Canvas is also very Customer-Driven. Yet, there has not been in the past an easy way to plan a detailed Business Architecture model starting from a Business Model Canvas to enable marketing and operation planning. In this article, we will demonstrate how to easily bridge a Business Model Canvas to a Business Architecture model to optimize with agility your marketing and operating modeling.

"I’ve observed a disconnect between stakeholders from the Pentagon and the engineers building the system. I’d like to show you a new technique called Behaviour Driven Development (BDD), which can help us explore how software will behave BEFORE it’s built”.

An analyst must frequently contend with structure-less environments and relentless rejection, and the character of Alice highlights many desirable characteristics that constitute the makeup of a good business analyst. Having identified the value of the Mad Tea Party as a learning ground in the previous episode of this series, we will now examine some of the key lessons learned and how they are applicable to the work of the business analyst.

A list of business analysis techniques is pretty extensive and from year to year new techniques appear, or become more formalised, and are adopted by business analysts all over the world. Some techniques become more popular and are widely used and some are used rare or only when a specific need arises. But definitely there are techniques that became very popular and are used on a daily basis and even become buzz words for some people. These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use.

By signing up to go through this process, you will be doing yourself a huge favor – a favor that you will never regret especially when people will look at you as the ‘wow’ person who completely transformed his or her life, achieving something that was not even vaguely possible otherwise.

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

Operational business decisions happen every minute of every day in your organization. You’d like to think that business managers can truly manage them. You’d also like to think that the results of those decisions are comprehensively correct, consistent, traceable, and repeatable (high quality). But are they? Based on real-life evidence I strongly suspect they often are not.... When IT professionals talk about “decisions” they often mean branch points within the deep systemic logic executed by machines – classic decision points in data processing. I don’t mean that either.

The difficulty of gathering information and establishing requirements, owing to the chaotic nature of the business world, is clear to see. Every business analyst must overcome their own Mad Tea Party if they are to be successful in carrying out their mission. As Alice is confronted with the unreliability of the Hatter, the March Hare, and the Dormouse, so too is the analyst faced with unreliable stakeholders. In her attempts to gain an understanding of the never-ending tea party, Alice’s use of elicitation is effectively useless in the face of endless riddles, an unconventional sense of time, and undependable characters.  Analysts find themselves in comparable environments with various degrees of chaos and unpredictability. 

We implemented A/B testing into our product 6 months ago. During that time we conducted a variety of A/B tests to generate insights about our user's behaviour. We learnt a lot about our specific product. More generally, we learnt about how to run valuable A/B tests.

Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.  When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.

Chaos, by its very nature, is impossible to control completely, and so a business analyst who enters into their own chaotic Wonderland will be presented with difficulties immediately. Throughout Alice’s adventures down the rabbit hole, she is confronted with a complete absence of structure, a lack of clear information, and a cast of frantic characters. In their role, a business analyst must strive to find order in the chaos, just like Alice. As Alice is faced with riddles, the business analyst is faced with information that is either unclear or unavailable. They must solve the riddles and establish structure, all while appeasing the residents of Wonderland.

Visit any active discussion forum for business analysts and aspiring BAs, and invariably you will find at least one thread asking how to develop domain knowledge, either in a new industry, such as health or insurance, or a new business function, such as marketing or supply chain management. Alice just got a job working for the first time in financial services, and is worried that her lack of experience in this domain will get in the way of her doing a great job. Bob keeps getting his resume ignored for analyst jobs in government agencies because most of his experience is in ecommerce applications. What to do?

To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand.