Over the last two decades, most organizations have moved away from the waterfall approach to the Agile approach. The agile approach allows us to develop things in an incremental way, allows us to experiment and seek constant feedback from our stakeholders. Agile business analysis is definitely a quite interesting topic to discuss.
Let me make a disclaimer first that when we are discussing a business analyst in the IT industry, we primarily referred to a person who is a business requirements analyst. (I have strong reservations about it but it hardly matters against a convention.) Business requirement analysis is definitely a critical element of any IT project and indeed a key part of business analysis.
Before we jump into the topic of agile business analysis let’s look at agility from the mother website which is Agile manifesto and what does it mean to business analysis community.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
When we look at the manifesto, we are very clear that the project team needs to deliver features of value to the stakeholders as soon as practically possible. Obviously, as business analysts, we also need to mend our way of working to ensure that we deliver critical requirements to our team in an iterative model.
I remember some of my old projects, that I worked about 25 years back, we would spend considerable time and effort in trying to elaborate all requirements in the requirements phase of the project. That’s a clear NO in Agile environment.
What we need to do is to just enumerate the features or requirements that we wish to have in the product and then prioritize them over different releases and iterations. We only need to work on the high priority features and requirements which are of maximum value to the stakeholders. This means we also need to continuously work with her project themes to work on requirements that the team would work on in subsequent iterations.
I am still not very clear how agile world would like to handle few things in business analysis. 5 key questions those trouble me are:
- Do we need a business analyst in agile projects?
- Can requirements be part of the same sprint?
- Do we need lower level documentation of requirements other than acceptance criteria?
- Should we bother about traceability?
- What happens to our good old modeling notations, especially UML?
Twister #1 Do we need business analysts in agile projects?
Popular Agile mythologies such as Scrum do not have a role called BA. The Scrum team is supposed to multi-skilled.
What has been your experience in this regard? Did you truly have projects where there was no person playing the role of BA? Could the product owner be the BA for the project team?
Twister #2 Can requirements be part of the same sprint?
In tons and tons of agile literature, we all have been told that during a sprint, the team completes requirements, design, development, testing, and deployment. Other than deployment, rest all are mandatory.
Looks so picture perfect. But does it happen in real projects?
To me, I have worked on projects which are following sprint-based approach but we do not work on requirements in the same sprint. Same case when I talk to my fellow requirements engineers/business analysts from other companies. It is indeed a near impossible task to complete requirements in the current sprint.
The reason is profoundly simple: Design, development, coding, testing, and deployment is under the team’s control, requirements are not.
Requirements need much more deliberation with stakeholders. Many often stakeholders themselves may not be clear about the requirements themselves. Trying to complete requirements in 2 to 4 weeks’ time, even for small features cannot be done in a multi-stakeholder scenario.
It makes immense sense to work on requirements one or two sprints prior to the sprint for development. That way the product owner/business analyst gets the required time to build consensus on the requirements.
Let me know your thoughts on this.
Twister #3 Do we need lower level documentation of requirements other than acceptance criteria?
Should business analysts prepare for detailed documentation for a feature or a UI in agile projects?. Does it make sense for the business analyst to spend some time in providing clarity on this before passing it into the development team? In my personal opinion, there are requirements which are pretty much knowable by the business analyst prior hand and requirements which are difficult to know up-front. It makes sense to spend some effort to elaborate requirements which are knowable and not spend much effort on requirements which are hard to know up-front.
Coming back to the question of documentation, theoretically, we should have a minimum of front documentation and then go back and update the documentation once the feature stabilizes. But how often do we really do that? It looks like the documentation remains very sketchy. Subsequent maintenance is bound to suffer because of the approach of not documenting enough for future maintenance. Once again, I would like to have the opinion of fellow business analysts about how they do things.
Twister #4 Should we bother about traceability?
Should we establish requirements traceability in an Agile environment? Most of the projects that I have had an opportunity in an agile environment, did try to establish traceability with respect to the test cases, so as to ensure the quality of the product. But traceability to the design elements or code elements was non-existent. I would like to learn from my fellow Agile business analysts about how they perceive things about traceability in an Agile environment.
Twister #5 What happens to our good old modeling notations, especially UML?
Coming back to modeling aspects of requirements in the traditional world we placed a lot of emphasis on UML which I do not see today. in my opinion some of the UML elements in actually wherein the solution in Domain, for example, Class diagram for sequence diagram which anyway was not part of business analysis activities.
However I still feel strongly that prototype, process model (now fancily called Story map), state model and use case model can add significant value to any project whether you follow waterfall or agile.
I authored a book on Agile business analysis which is available on our portal for your review and comment. Those of you who have significant experience in Agile business analysis, you can message me for a free copy of the book for your reference in return for your contribution to help make this back book better for all agile business analyst community.