Writing functional specifications as a business analyst (BA) in an agile ecosystem is a challenge of a different kind. You no longer have the luxury of time (unlike bigger waterfall projects). You no longer can be sure with a specification version as the final document (because of the iterative philosophy). You are not sure how comprehensive the functional specification should be (Agile manifesto: working software over comprehensive documentation).

Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren’t there? Or our vocabulary shrank like ‘Honey I Shrunk the Kids’?

Next to silence, words are a very important part of our conversations :-). When it comes to Business Analysis, there are many challenges around definitions. The project Glossary should contain all key business terms. It is such a straight forward thing but we may assume those things. We may put a little less emphasis on creating a rich project Glossary. Let us zoom in a bit into the common challenges of glossaries and also discuss how to overcome them.

This article discusses extensions to commercially-available requirements management (RM) and application lifecycle management (ALM) tools. These extensions are intended to support the concepts presented in the Requirements In Context (RIC) series of articles. End-to-end requirement examples based on those concepts can be seen in the Trips-R-You Web-based Flight Reservation System Case Study... All RM/ALM tools, ‘out of the box’, should support the concept of Requirement. The typical form of support involves a textual requirement Description, accompanied by properties such as Priority and Status. It’s left to users of the tool to manage the description content (and quality).

Someone recently asked me “What does a typical day for a Business Analyst look like?” and my response was that if you do find someone who can articulately answer that question, they are probably a very good Business Analyst to start with. No two days look the same in this profession. A person in this role must have many facets to their personality in order for them to be a confident and a strong Business Analyst. I really like the business analysis profession because there are multiple dimensions to the various roles we may be asked to fulfil.

Being a Business Analyst has largely shaped my career and it has also played a big part in shaping my personality. What’s it about this role that has the potential to make a professional grow into a strong and a confident character? The purpose of this article is to talk about these aspects and show how a Business Analyst can use these aspects to their advantage to not only become the best Business Analyst that they can be but also to be a strong and confident personality that will help them at any turn of life; professional or personal.

Agile projects, due to the short cycles of delivery, require a collaborative team, substantial leadership support, and a robust, agile culture to be in place to be called as working and successful.

The two key pillars for a successful agile project are the product owner and the business analyst.

The product owner works almost like the director of a movie, envisioning the macro and micro-level details for the product. At the same time, the business analyst ensures smooth execution of the sprint and manages the epics and stories' details.