My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework).

Ever wondered how to write foolproof acceptance criteria? Or even wondered what a business analyst can do to ensure that requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. A business analyst plays a key role in defining the tests around it. The acceptance tests can be at various levels of requirements detail. Starting from high-level requirements to detailed requirements. Let’s take a look at common challenges involved in this part of the world, along with a few ideas to overcome those.

For the past year the COVID-19 virus has forced us to limit our exposure to the outside world. This virus has given us a need to find a home activity to entertain ourselves and our families. One of the activities I have pursued is assembling jigsaw puzzles. As you may know, a jigsaw puzzle is a challenge in assembling picture pieces into a single image. They come in various shapes and sizes. After doing a number of these puzzles, I noticed the similarity between this fun activity and executing a project.

Business is rarely 100% smooth sailing. Regardless of the industry or sector, there are always challenges to overcome and obstacles that must be faced on the pathway to success.

Some organizations aren’t strong enough to ride the waves. Others, however, are, and the reason for their strength is that they’re not navigating the murky waters alone - they’re supported by an ambitious, results-driven business analyst. Research even shows that business projects are more likely to succeed with the help of a great BA.

At their core, business analysts are part problem solvers, part change-makers. The core responsibility of a business analyst, or BA, is to work with organizations to identify a sticking point that’s standing in the way of them achieving their goals, introduce a solution to this problem, and help the business to adapt in a way that makes it easy to implement the solution into the business environment.

Typically, a great business analyst is someone that’s confident enough to think outside the box, who’s solution-oriented and innovative. But today these skills alone aren’t enough, especially as the role of the BA is changing.

     Continuity planning can occur at many levels including at the project, department, organizational, or enterprise level. At the project level, a business analyst considers what will happen if a project solution fails or underperforms. This is usually documented in the form of transition requirements. At the higher levels, a business analyst collaborates with organizational leaders in key areas to determine the steps that need to be taken in the occurrence of major events that significantly disrupt business operations. With that said, I’ll be discussing the role a business analyst can play in developing an effective continuity plan.

     First, let’s discuss what a business continuity plan is. Essentially, this is a comprehensive plan to make operational changes that will allow an organization to continue business or services through a crisis, disaster, or operational disruption. The process of developing and maintaining this plan is known as business continuity planning. Typically, business continuity consists of the following three key areas...