Welcome to part 4 of our 5-part Behind-the-Scenes in Business Analysis series where I’ll walk you through how I’ve handled some of my most interesting business analysis projects using the business analysis process.
Part 5 – where we look at how the BA process applies to agile, because despite what you might be reading out there, agile environments absolutely, positively need business analysis.
Two Locations, Two Perspectives
Let’s start at the beginning. When I landed this consulting engagement, I wasn’t hired because I knew about agile. (I didn’t know much at all about agile as it was just becoming a “thing” at that time.) I was hired because I was experienced with use cases and customer-facing web applications.
Despite this perception of expertise, this was one of my very first projects working with internal users and on the systems they used as part of their day-to-day work, and that brought some fresh challenges into the mix.
Let’s dive right in.
The organization is geographically split. The primary executive stakeholders are here in Denver, along with the technical project manager, and the primary business stakeholder, and me. The primary business subject matter experts, those that deal with the key processes day-to-day, are over in the Eastern time zone.
Although the vision from leadership is clear, we don’t have a detailed insight into how the business process actually works. To resolve this lack of understanding, the three of us visit the second location to meet with the experts early on in the project, just about the time I’m finishing up the first draft of the 8-or-so page scope statement.
The primary business stakeholder does a beautiful thing and I’ll always be grateful for what I learned from her. She keeps the discussion focused on their problems and their needs. She speaks to the goals of the executives in ways that matter to these experts.
And then she does something even more beautiful. She suggests we adjust the scope of the project to address some of their primary concerns. She essentially goes to bat for them to the executives back here in Denver and renegotiates scope and expectations.
(In step 2 of the business analysis process, it can be important to help stakeholders from different levels and parts of the organization get aligned on the business objectives to be addressed.)
With this action, she essentially creates the circumstances for a successful project. You see, the experts don’t trust anyone – not us, and definitely not the executives. They are engaged in the project only to the degree that they need to be to avoid being insubordinate. With this one move, the project manager shifts their perceptions and gets them more fully engaged. She essentially paves the way for me to have a much more effective elicitation and analysis process.
Start Planning, and Then Re-Planning
With a scope that has more stakeholder buy-in than we could have expected at this point, we begin fleshing out the requirements. Traditionally, this organization has created use cases, so I do the logical thing. I create a use case list and begin mapping out a plan to put the use cases together.
Then we have our kick-off with the development team to discuss the solution approach in more detail. It turns out that the development team is an agile shop. They don’t want use cases. They want user stories.
Hmm…
User what?
User stories.
I get a 5 minute tutorial from the technical lead and am sent on my way.
Create us a product backlog, they say. Then we’ll start designing and implementing the system.
Hmm…
For a few days, I am stopped in my tracks. I am in a learning frenzy trying to figure out what’s expected of me.
I finally start breaking down my use cases into what seems to be a reasonable set of user stories as a way to get the product backlog going. We review it as a team and there are head nods of approval, so I feel like I’m generally on the right track.
Getting Something Ready for Sprint 1
But now, I’m under time pressure. Sprint 1 is supposed to start in less than a week. We select a few user stories for the first sprint. Because I’ve been so worried about how to specify the requirements, I didn’t allocate enough time to actually elicit and analyze the requirements. I hit a snag and learn we need to engage additional stakeholders to confirm a few requirements.
I really need a few more days to get the requirements complete and validated (all part of step 5 of the business analysis process), but we don’t have it. Instead, I’m told by the team that change is fine. Give us something and we’ll work with it. We can always change it later.
So I do.
Two days into the sprint, I’m able to finalize the requirements. And yes, as expected, they’ve changed. I email the developers summarizing the changes, expecting them to incorporate the changes into the sprint.
It’s a no go. Instead, they say they will build off the original requirements and incorporate the changes in the next sprint.
This response made no sense to me. I’m beginning to think there is something wrong with this whole agile thing.
But being new to the process and somewhat of an outsider, I played along. I dutifully went into sprint 2 with a list of changes to what had been developed in sprint 1.
At this point, the developers didn’t seem so excited about changing what they’d just invested two weeks of work in.
That’s when I learned an important lesson. There is a difference between your process supporting necessary change and personally embracing the impact of unnecessary change. Because I didn’t hold fast to the fact I needed more time to validate the requirements (something we talk about how to do in the BA Essentials Master Class), I enabled a situation where our team had to deal with unnecessary change.
The silver lining is that because of this rework, I was able to get just enough ahead so that this problem didn’t repeat itself again.
Getting in Sync and Making Good Progress
From sprint 2 on, consistent progress was made. Every two weeks I saw what the developers had completed. Every two weeks, I prepared new requirements for them to work with.
Within the first few sprints, we developed some productive working rhythms organized around our bi-weekly sprint planning meetings:
- I met with the technical team once every two weeks to review new stories, scope them using story points (a way of estimating), and build my awareness of technical opportunities and complexities.
- I met with the business sponsor every two weeks to prioritize new stories and confirm the next set of stories in the product backlog.
- I worked forward one or two sprints to elicit and analyze the details for the upcoming stories, build wireframes, and write out acceptance criteria.
Overall, we ended up finishing the bulk of the project in 8 or 9 sprints, plus a couple of extra sprints at the end to fix bugs.
By the end of the project, I was a stronger a proponent of agile methodologies. By and large, they worked.
What I liked most was that the requirements were integrated right into the development planning process. Disconnects I’d witnessed on past projects between use cases, project schedules, and technical design documentation disappeared.
Of course, keeping the requirements aligned with the development plan did take a lot more time from me as the BA. It was necessary to package and repackage the requirements based on the implementation plan. But in the end, this alignment led to a much cleaner product.
Despite the wins, there is one issue that we didn’t get to discuss yet, and that was losing track of the big picture.
Losing Track of the Big Picture
To support planning, prioritization, and development, user stories tend to get broken down in a fairly granular way. As a result, you can lose the big picture of how they all fit together. By the time we got to sprint 6 or 7, it became increasingly difficult to prioritize user stories or present a clear picture of what had been implemented vs. what remained to be done. We had well over 60 user stories and it was simply too much information to keep present of mind.
To address this issue, I ended up creating what I later learned was a lot like a user story map. It was essentially a visual flow of how the user stories worked together to deliver on the business objectives and features in the project.
This was valuable in our final prioritization efforts as we were deciding not just what user stories would be next, but what would get into the final release and what might not make it. We could see if we had missed any critical threads of functionality and decide how to group the user stories together for maximum business benefit.
The lesson here is to not be afraid of adding a new visual model to the mix, even late in the cycle, especially if there’s a decision that’s difficult to make or a set of information that’s difficult to understand.
This picture solved a lot of problems for those of us entrenched in the project day-to-day, but it didn’t do much good for our experts over in the Eastern time zone. Let’s take a look at how we engaged them next.
Getting the Experts to Use the New System
First, I documented the updated business processes to be used by the users, taking care to frame the processes from their perspective, not a functional perspective. We walked through this process documentation while demoing early versions of the new system, still in development.
Then, I stepped in to lead a user acceptance testing effort. Since the business users weren’t super technically savvy, I mapped out scenarios and test cases. I visited their office so we could run through them together as they each took a turn using the new system.
This approach had many benefits. With this one activity we witnessed their first-hand reaction to the new way of doing things, validated the system worked for the business process, and trained them on the new business process.
Once the system was live in production, I was on hand to answer questions, but things worked pretty seamlessly and I moved on to other clients.
Looking at Lessons Learned
Let’s look at our take-aways:
- Expect the unexpected and be flexible. No matter how well-thought-out your business analysis plan, projects face unexpected changes in circumstance. In this case, the development team brought a methodology we were all expected to work within. Being flexible afforded me the opportunity to learn a new skill set.
- There are different types of change. At first, I too fully embraced the agile rhetoric and allowed incomplete requirements to go to implementation. This backfired, luckily in a small and easy-to-recover from way. Distinguish between necessary change, which happens when external factors require you to rethink requirements, and unnecessary change, which is the result of incomplete analysis. Agile makes it easier to deal with necessary change. Unnecessary change still costs unnecessary money.
- You are not done until the business gets it. While working in product environments, I had very little exposure to real users. By getting involved in user acceptance testing and business process modeling, I got a much better perspective on how system changes directly impacted the business users. I started to see the BA role as much broader in scope than I had previously. It’s not just about getting the software system deployed. It’s about getting the users to use that system successfully. (This is why step 7 of the business analysis process helps ensure the business community is prepared to embrace the changes that have been specified as part of the project.)
Here we are, all the way at the end of the last installment in this Behind-the-Scenes in Business Analysis series. I hope you’ve enjoyed the content and learned something new that makes you more effective.
You can also check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.
