I hope the above two examples give you an idea about how different the projects use agile principles based on the nature of the project. And I believe this would give you some tips if want to adjust the existing agile practice in your project too. So, the BA’s who have not worked in agile projects before, now you know how the real world agile projects are….

If you surf the internet for ‘agile project methodology”, you may get lots of web pages explaining a similar set of activities which are /should be followed in Agile projects.  Unless you have working experience in an agile project environment, you may imagine what a well-defined and smooth process the agile projects have!! 

What if you have really worked on an agile project, would you have the same perspective? Especially if you are a Business Analyst or an Iteration Manager…. ? Those BA’s and IM’s… I know what your answer is and the long explanation about your agile project experience is.. I can imagine even your annoyed faces …

Whether you’re purchasing a package (also called commercial off-the-shelf, or COTS, products) as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs.

Having discussed fields intended to name record instances, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision. 

Sometimes the best solutions are right in front of us, hidden in plain sight. Get in the habit of working from first principles and you’ll find it easier to cut through preconceptions to change the business question and quickly see alternatives that you may have missed.

The objective of this article is to help business analysts capture functional requirements for an information system as User Stories. It discusses four levels of story. The first two levels represent business context. Levels three and four involve functional detail needed by developers and testers to deliver stories at those levels.

Where an organization opts to move into agile methodologies that help to provide quick and customized solutions, it is imperative to use a technology that supports agile workflow and application development.

There are several Frameworks and Programming Languages in the market that help in building Agile Solutions but as compared to all the available Stacks, PHP is the one that Comes up with a collection of Potential Frameworks that are actually contributing well in developing effective Application Development.

The PHP frameworks are a set of process conventions and technologies that simplify and accelerate application development and maintenance. A framework provides certain functionalities to an application through ready-made features and practices.

In this article we focus on record name fields. These fields are intended to contain a user-recognizable value by which a person or thing is known, addressed, or referred to. Unlike a record business identifier field, a name field’s value may change over time. Also, there are ‘real world’ names for things (e.g. people, cities) for which valid duplicate values can exist. 

It is more than important the modern business analyst to focus on the end to end customer experience. A BA shall act as a consultant that listen to the pains of the end users and is dedicated in solving them through providing solutions that will alleviate those pains.  How do you define a customer-centric mindset you can actually execute? Below are some elements of the customer – centricity mindset...

As Business Analysts, when we’re at the sharp end of solution delivery that doesn’t match a customers needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages. In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements. 

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile.  A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.   

Being successful as a business analyst is not a feat - reserved for a select few. Neither is it rocket science. It is achievable and within your grasp, if you apply a well-rounded approach to how you manage your career. While these tips are centered around the business analysis career, they can be applied to any career.

We hear the buzzword “business transformation” everywhere. It has become almost expected of any organization to announce they are on their digital transformation journey. What does it mean?

There are many definitions of digital transformation. This abundance points to a broad interpretation of the term. The ambiguity of these statements reflects vague expectations of many organizations embarking on their “digital transformation journeys”.

What is Use Case?

Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb.

A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether.

What is User Story?

User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though

User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board.

Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases.

Having explored information system record concepts, the objective of this article is to examine one particular type of field — the record business identifier. Its purpose is to uniquely identify an instance of a record.  Users of an information system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with the specific record instance it identifies.