Share this
5 Brain Twisters for Expert Agile BAs
by LN Mishra, CBAP, CBDA, AAC & CCA on Sep 29, 2017 12:00:00 AM
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.
Share this
- Business analysis (135)
- CBAP (41)
- Business analysis skill (34)
- CBAP Certification (32)
- #CCBA (31)
- Career (29)
- ECBA (22)
- #AdaptiveUS (20)
- #BA Certification (18)
- #BA (16)
- IIBA Certifications (16)
- BABoK (15)
- #IIBA (14)
- #AdaptiveUS #BusinessAnalysis (13)
- Uncategorized (13)
- Most Popular (12)
- Announcements (11)
- cbap certification training (11)
- Requirement engineering (10)
- #CBAP_Certification (9)
- #LNMishra (8)
- countdowns (8)
- #BA Skills (7)
- CPRE (7)
- Press Release (7)
- #BA Techniques (6)
- #BusinessAnalysis (6)
- #CCBA_Certification (6)
- #Elicitation (6)
- #AdaptiveUS #BusinessAnalysis #BA #BABoK (5)
- #PressRelease (5)
- #business analyst (5)
- #Business_Analysis (4)
- #ECBA_Certification (4)
- #Requirements engineering (4)
- #cbap_exam_ preparation_tips (4)
- #certifications #AdaptiveUS #BusinessAnalysis #BA (4)
- Business analysis certification training (4)
- Most Recent (4)
- #AdaptiveRocks (3)
- #BA_Certification (3)
- #IIBA Membership (3)
- cbap certification cost (3)
- cbap certification course (3)
- cbap training certification online (3)
- #LearnwithLN (2)
- Business analysis study guides (2)
- CCBA Recertification (2)
- CPOA (2)
- businessanalyst (2)
- cbap question banks (2)
- cbap study guide (2)
- ecba question banks (2)
- ecba study guide (2)
- #AAC (1)
- #AgileBA (1)
- #BAOT (1)
- #BATrends (1)
- #BridgingtheGap (1)
- #ECBA #IIBA #IIBAWorkshop #Certification (1)
- #IIBA #Agile (1)
- #IIBAEgyptChapter (1)
- #IREB (1)
- #NFR (1)
- #OneWorksGroup (1)
- #Partnership (1)
- #SimpleSim (1)
- #ba #businessanalysis #jobdescription #adaptiveus (1)
- #performancemetrics (1)
- Adaptive US (1)
- Agile BA (1)
- Artificial Intelligence (1)
- Awesome BA (1)
- BABoKV3 based certification (1)
- BACOE (1)
- CBAP Certification Tips (1)
- CBAP Exam Preparation (1)
- CBAP Exam Tips (1)
- CBAP Preparation Tips (1)
- CBAP certification preparation (1)
- CBDA (1)
- ECBA Certification steps (1)
- ECBA V3 certification (1)
- ECBA certificate (1)
- From our Archive (1)
- IIBA CBAP Certification (1)
- KPI (1)
- PMI PBA (1)
- PMP vs CBAP (1)
- Requirements Management (1)
- Scrum (1)
- Scrum rules (1)
- Transitioning to BA (1)
- bajobs (1)
- cbap e-learning (1)
- cbap training material (1)
- ccba certification training online (1)
- ccba or cbap certification (1)
- conflicts resolution techniques (1)
- iiba ecba online course (1)
- productowner (1)
- stakeholders (1)
- testing (1)
- what is scrum? (1)
- May 2023 (2)
- April 2023 (4)
- March 2023 (3)
- February 2023 (5)
- January 2023 (1)
- December 2022 (4)
- November 2022 (3)
- October 2022 (2)
- September 2022 (4)
- August 2022 (3)
- July 2022 (4)
- June 2022 (8)
- May 2022 (4)
- April 2022 (7)
- March 2022 (6)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (4)
- October 2021 (4)
- September 2021 (2)
- August 2021 (4)
- July 2021 (4)
- June 2021 (2)
- May 2021 (1)
- April 2021 (1)
- March 2021 (4)
- February 2021 (2)
- January 2021 (3)
- December 2020 (3)
- November 2020 (3)
- October 2020 (3)
- September 2020 (5)
- August 2020 (8)
- July 2020 (3)
- May 2020 (5)
- April 2020 (2)
- March 2020 (7)
- February 2020 (6)
- January 2020 (4)
- December 2019 (1)
- November 2019 (3)
- October 2019 (5)
- September 2019 (3)
- August 2019 (2)
- July 2019 (4)
- June 2019 (2)
- May 2019 (3)
- April 2019 (6)
- March 2019 (3)
- February 2019 (8)
- January 2019 (7)
- December 2018 (8)
- November 2018 (6)
- October 2018 (8)
- September 2018 (11)
- August 2018 (11)
- July 2018 (23)
- June 2018 (12)
- May 2018 (19)
- April 2018 (11)
- February 2018 (1)
- January 2018 (3)
- December 2017 (1)
- November 2017 (5)
- October 2017 (2)
- September 2017 (2)
- August 2017 (30)
No Comments Yet
Let us know what you think