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 and experiment and seek constant feedback from our stakeholders. Agile business analysis is definitely quite an interesting topic to discuss.
Let me make a disclaimer first that when we are discussing a business analyst in the IT industry, we primarily refer 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 a critical element of any IT project and 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, the Agile manifesto, and what it means to the 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.
[Source: AgileManifesto.org]
When we look at the manifesto, we are very clear that the project team needs to deliver value features to the stakeholders as soon as 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 the old projects that I worked on about 25 years back; we would spend considerable time and effort trying to elaborate on all requirements in the requirements phase of the project. That's a clear NO in an Agile environment.
What we need to do is 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 unclear how the agile world would like to handle few things in business analysis. 5 key questions that 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 be multi-skilled.
What has been your experience in this regard? Did you genuinely have projects where no person was 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 the team completes requirements, design, development, testing, and deployment during a sprint. Other than deployment, the rest all are mandatory.
Looks so picture perfect. But does it happen in real projects?
I have worked on projects that follow a sprint-based approach, but we do not work on requirements in the same sprint. It is the 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 are 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. Even for small features, completing requirements in 2 to 4 weeks 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 providing clarity on this before passing it to the development team? In my opinion, some requirements are pretty much knowable by the business analyst prior hand and requirements that are difficult to know up-front. It makes sense to spend some effort to elaborate knowable requirements and not spend much effort on requirements that 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 to ensure the quality of the product. But traceability to the design elements or code elements was non-existent. I want to learn from my fellow Agile business analysts how they perceive 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 was not part of business analysis activities.
However, I strongly feel 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, available on our portal for your review and comment. Those of you who have significant experience in Agile business analysis can message me for a free copy of the book for your reference in return for your contribution to help make this book better for all agile business analyst communities.
Contact Us
No Comments Yet
Let us know what you think