Project Management

How the Business Analysis Standard Could Have Helped an Agile Transition

From the Building the Foundation: The BOK on BA Blog
by , , ,
A new collaborative blog featuring the contributions from the core team members of PMI's Foundational Standard in Business Analysis. This blog will provide the community with insight into PMI's development of the standard to generate professional discussions about the content in advance of the scheduled reviews.

About this Blog


View Posts By:

Laura Paton
Joy Beatty
Cheryl Lee
Sue Burk

Recent Posts

PMI's Newest BA Standard and the PMI-PBA Credential

An Update On PMI's Consensus Based BA Standard: The Final Phase

The Link Between Business Analysis and Project Management Processes

Party Like a Business Analysis Rock Star!

PMI’s Business Analysis Standard – What You Have to Gain

Categories: Business Analysis

While the team is collaborating on PMI’s business analysis standard, we have been very conscientious about making sure we are not favoring predictive over agile approaches, or vice versa. We are focusing on covering topics as inclusively as possible, while also offering suggestions on how to adapt activities to any approach. I promise we will have more to say on this in future posts!

For now, I wanted to share some examples to demonstrate we are being agile-friendly when developing the standard. Our work is based on community research to understand what common and best practices are. However, we also learn a lot when things do not go as smoothly as desired, so it is interesting to think about those situations also.

One particular experience in a large organization actually inspired many ideas for me. This large global organization was making a transition from a waterfall to an agile delivery approach, and like many others, ran into some issues. Here are the most critical issues with which our business analysis standard could have helped.

Issue #1: Throwing the baby out with the bathwater

This organization previously demonstrated really strong business analysis practices in waterfall approaches. They understood projects’ business objectives, they created detailed visual models to guide their requirements, and they wrote nice requirements statements. However, during the transition to agile, the business analysts were scrambling to find a role. They jumped right in to help write user stories and acceptance criteria—not a bad idea in and of itself. However, that is all they wrote—lots and lots of textual user stories. The entire team filled the backlog with user stories simply by brainstorming to see what came to mind. Then, the team prioritized the user stories based on what the business said was most important instead of looking at the business objectives. It is as if they forgot all of their good business analysis practices when they moved to an agile approach!

We hope to help: This business analysis standard will hopefully be a reminder, evidence, and explanation of how business analysis is just as important in agile approaches as in others. For example, the team could still create visual models to help identify or explain user stories and acceptance criteria. Similarly, the business value or business objectives are perfect to help prioritize the backlog against something other than intuition.

Issue #2: Being an agile purist

This organization had previously been coached that being purists was the only way to deliver with agile approaches. Their biggest and highest risk project was using agile practices, but the others were not. Not surprisingly, this generated a lot of tension between the waterfall projects wanting to only receive interface requirements up front and the agile team not wanting to commit to what they would build or need in their attempt to be purists. The solution they eventually landed on was to temporarily create agile requirements documents. Many agile purists would have cringed! However, the agile teams documented “just enough” about what they would need from the waterfall project teams so those teams could plan for the interfaces. They documented a little bit about each interface they knew about up front with the equivalent of business requirements.

We hope to help: The standard will help offer suggestions about how to adapt business analysis practices for agile approaches, but they are only suggestions and are clearly labeled that way. As Cheryl nicely explained in a recent post, there are many ways to perform the business analysis processes. This team would be the first to admit there is no one size fits all “way” for any of these practices, including the agile ones. Organizations have to determine how they wish to use (tailor) the guide to the culture and operating environment of their corporation.

Issue #3: Waterfall communication style for agile interfaces

When the organization first started using agile on the large project that interfaced to many others, they had excellent communication within the agile team. However, they neglected to plan for similar levels of communication with the non-agile teams. The reality is, they probably needed more communication with outside teams than with their own. There were so many interfacing project teams that just jotting down requirements about interfaces was not enough; it took a somewhat intimate understanding of the interfacing systems to know if the details were all understood. By the end of the project, the agile team actually had a full-time resource whose job was to talk to all the interfacing project teams on a regular basis to identify areas of risk, points of conflict, and high priority interface requirements.

We hope to help: The collaboration points from Business Analysis for Practitioners: A Practice Guide were well received in the community because they help you think through how you might collaborate with project managers. This standard will continue that spirit with even more ideas about whom you might collaborate with and on what!

PMI’s business analysis standard probably won’t be the answer to all problems that organizations face in their transition to agile. However, I can assure you there will be a substantial amount of content about what things you can do with business analysis in agile.

Posted by Joy Beatty on: August 26, 2016 10:12 AM | Permalink

Comments (5)

Please login or join to subscribe to this item
The worst thing we can do to create an standard (mainly a BOK) is to reference it inside an approach. And if we talk about agile, we need to understand that business analyst role is a key success factor to implementa agile BUT if and only if organizations (and business analyst) firmly understand what agile is. Agile is not a method or methdology, agile is not a life cycle, agile is not software or IT related only, agile did not start with the agile manifesto for software development. I have wrote a short article inside PM Network ("Perfectly Positioned", English:
Heidi Arraya has published a great brief to understand that:

Sergio, thanks for the comment. I agree with your point - that a standard or BOK isn't something to reference within an approach. I rather think of these as things use to guide you as you develop an approach. This standard is suggesting the tasks that are commonly performed and how to tailor them for predictive and adaptive approaches.

Thank you very much. All your work will impact in work or people like me that are working with Business analysis. That is because I am particiting so often. Thank you very much for being patient.

Thank you very much Joy. All your work and your team work creating the standard will impact to people like me that are working with business analysis and agile at organizational level. That is because I am making my comments so often. Thank you very much for being patient.

"Approaches for agile, iterative and adaptive environments" will be integrated into the upcoming edition of PMBOK. I'm assuming that your standard will align with the upcoming PMBOK?

Please Login/Register to leave a comment.


"Creative minds have always been known to survive any kind of bad training."

- Anna Freud