While our team was collaborating on PMI’s business analysis standard, we were very conscientious about not favoring predictive over agile approaches, or vice versa. We focused on covering topics as inclusively as possible, while also offering suggestions on how to adapt activities to any approach.

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

One particular experience in a large organization actually inspired many ideas for me. This 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 their projects’ business objectives, created detailed visual models to guide their requirements, and 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, which is 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!

How the standard helps: The standard our team worked on is hopefully 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. However, the business value or business objectives 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 project teams that only wanted to receive interface requirements up front and the agile team that didn’t want 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.

How the standard helps: The new standard offers 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 business analysis processes. This team would be the first to admit there is no one-size-fits-all “approach” for any of these practices, including the agile ones. Organizations have to determine how they wish to 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 a 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 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.

How the standard helps: 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. The standard our team developed continues 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 you can do with business analysis in agile.

You can comment here or join the conversation over at projectmanagement.com on the business analysis blog.