With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work. We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.
The Business Analyst is in a great position to constantly focus on the desirability of the product. A well-defined requirement elicitation process must be focused on defining the problem the business is trying to solve for our customers. If defining the problem is the first step in your requirement process you are on the way to guaranteeing that the delivered product will provide value to your customers. Throughout the development process you will be able to monitor if the product is actually solving the problem. Additionally, your requirements should be directly related to solving the problem. It is a BA’s job to question the value of every proposed requirement that product owners want to add. If the requested feature or function is not directly related to solving the problem then it should be taken out of scope.
To be a great analyst, you’ll need to ask great questions. In order to ask great questions, you’ll need to remain inquisitive. Fact of the matter is, that if you are performing any kind of analysis, you need to become very comfortable with asking difficult questions. Questions that make people uncomfortable and questions that might even potentially expose unpopular answers.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us