Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump straight into a solution. However as BAs we first need to understand the problem area better.

As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the business analyst (BA). Below are some steps to help business analysts navigate their way through the transition to agile and add the most value to their agile teams.

Surely facilitation is an important part of a business analyst’s job, but it is far from the only part. Analysis in itself should always form the core of a business analyst’s responsibilities.  We are called ‘analysts’ for a reason! Facilitating information gathering and translating it to ‘requirements’ doesn’t make you an ‘analyst’. Go above and beyond, and add value by ‘reasoning backwards’ and ‘reasoning analytically’.

 

One of the Sidebars to the Business Agility Manifesto introduces the notion of Reconfiguration Agility. It’s a fundamental capability your organization needs in the Knowledge Age. What’s it about?  In the big scheme of things, you have two basic choices for conceiving, and ultimately implementing, business capabilities: procedural or declarative. They are fundamentally different.  Traditionally, the vast majority of business systems have been modeled and constructed on a largely procedural basis – virtually all things tied together step-by-step in processes. Unfortunately, that procedural approach simply doesn’t scale.

With the help of visualization tools, data can be converted easily to more accessible form hence making it much simpler to understand. Data Visualization is available for both developers and for presentation ensuring ease of work for both.

First of all, let’s get this out of the way. Gamestorming is not new. Gamestorming is a collection of ‘games’ put together under the banner of ‘gamestorming’. As a business analyst (BA) I can assure you there will be many games in the book and on the website, that you have used in your role under different guises. 

Dave Gray (co-author of ‘gamestorming’) put it best when he described himself and his fellow authors as the Grimms brothers. The Grimms brothers, if you are not familiar with them- they brought together different fairy tales and published them in a book.

One of my former business analysts on the team asked me this question recently; ‘I am really over being a BA. How do I move into strategy?’ I got to the realization that she was associating ‘strategy’ with a job title which consists of certain tasks.  In my view, it appears as if for some business analysts, before becoming strategic, they have to be given a title ‘Strategic Business Analyst’. This I believe is the mystery that surrounds ‘strategy’ and ‘strategic thinking’, making it appear as a destination to reach, at some point.

Every profession in a sophisticated business structure has a certain mission attached to it. This mission includes the job duties and deliverables, but that’s not all.

The only way to really encapsulate the essence of what the profession of a business analyst is all about is to understand the Business Analyst Mission. In other words, the Business Analyst Mission is definitive of the value created by business analysts.

One of the Sidebars to the Business Agility Manifesto unabashedly indicts the software industry for its long-standing failure to provide direct support for obligations, an obvious and fundamental aspect of real-life business activity.

Where can you find obligations in business? Virtually everywhere you look: acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, licenses, citations, certifications, notices – and of course, business policies.

Direct support for obligations is a fundamental capability your organization needs in the Knowledge Age. What’s it about?

Most of us are well aware of the problem of organizational silos and non-integrated applications and channels. The question is how can we plan to eliminate them?   The notion of a value chain is to take a 10,000-foot view of the business based on how value is created incrementally toward final delivery of products to end-customers. In other words, a value chain model looks holistically at the value-adding capabilities of an organization end-to-end, irrespective of organization lines of responsibility or existing functional activities.

In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they’re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process. What makes requirements...

As a business analyst, one of the most valuable skills you can acquire is the ability to build relationships. This in itself may have more of an impact on your long-term BA career than your business knowledge and technical skills. Because BAs are often key participants in so many different projects and initiatives, it can be difficult to nurture all of the relationships established throughout your organization. The relationship that I will be focusing on, however, is the relationship with the developer(s). Solid business analyst-developer relationships are often easier to facilitate in agile environments; therefore, it is essential to put more effort into managing this relationship in an environment that uses a waterfall or traditional methodology. Below are some tactics we as BAs can use to make developers’ lives easier and enhance the business analyst-developer relationship.

The relationship between a business analyst and the stakeholders is one of the fundamentals to the journey of delivery. If the relationship is dysfunctional, the process of delivering the solution will be negatively impacted... Each one of us is blessed with a different personality that makes us unique. In the case of business analysts, personality plays an important role, thus making it a key to survival. Business analysts are adaptive survivors. It is imperative that every impacted stakeholder is engaged and collaborating. It's fundamental to a robust requirements analysis process. Having mentioned the need to bond with your stakeholders, let’s see what skills are needed to be a successful business analyst.

 

Decisions are at the heart of every business transaction. That’s why it is crucial to make the right decision at the right moment in time. In high turnover environments this can be an issue, as new staff need constant monitoring as they ‘learn the ropes’. This can lead to a significant deficit in efficiency and customer satisfaction.

 

To counter this problem, we advocate what we call a ‘Decision-Centric Approach’, which is designed to address the business challenge by enabling innovative technology in those crucial ‘moments of truth’

 

What do you put down in non-functional requirements when you are documenting requirements in your project? When we say non-functional we typically mean those requirements that are not related to functionality of the system, then what exactly are these and why do we need them.