One of the most important things a business analyst needs to understand is this:
Your users are not (in most cases) skilled application designers.
Your users are people trying to check a bank balance, or order Season Three of The Wire on DVD, or add a new employee to the payroll system. Most of them are not technologists. Seems pretty obvious, right?
So why am I bringing it up? Because very often, business analysts don't recognize the implications of this fact. Your users are good at finding problems with your system. They're good at evaluating potential solutions. They're good at telling you an implemented solution solved their issue. But what they shouldn't be expected to be good at is determine exactly what that solution should look like.
A business analyst needs to be an analyst, not a short-order cook taking tickets.
Let's consider an example. A user of our grocery delivery website has a fixed food budget each week, and it's important for him not to exceed that budget when ordering. However, we don't show the user in the shopping path information on how big their order currently is, so our user doesn't know if he can afford the T-bone this week, or needs to settle for burgers. We do keep track of the current value of the order, but it's on the "View shopping cart" page, so our user has to keep flipping back and forth between the shopping page and the cart page to keep tabs on his order.
Sounds good so far, right? There's a real problem here, and it's probably one that can be solved with technology.
The problem is that this isn't usually how the problem is presented to us. Very often, our users (in the process of being frustrated by something) will envision an idea that could solve the problem for them. And so what we get from the user will be a "feature request" that looks something like this: "When I go to add a new item to my shopping cart, I want a popup that says 'This will make your total order $X. Are you sure you want to add this item?'"
The wrong approach to this feature request is to ask "OK, what color do you want that popup?" Then add the request to the backlog and build it. The user asked for it! It's a user requirement!
A better approach is to start with the request, and work with the customer to understand the reason for that request. "OK, so help me understand how this popup makes life easier for you." "Well, I have a fixed budget, and I need to know if the item I'm adding is going to put me over that budget." "OK, and you need something new because you don't have a way to see that today?" "Right - the only place I can get the current order total is on the Shopping Cart page, and it's a pain to keep flipping back and forth to a different page. I need to keep track of this while I'm shopping."
Aha. Now we have the most important piece of a user story - the goal the user is trying to accomplish.
The feature injection approach to requirements is really useful here. You start by "hunting the value," then building the features you actually want to implement off of that. To borrow one of their techniques, I might write a user story for my customer's request "value first" in this case - In order to keep my order within my set budget, as a shopper I need a way to keep track of my order value from within the shopping path."
Now that we have the goal, we can leverage our skilled development team to come up with a range of ideas on how to meet that goal. Instead of showing everyone using the site a popup every time they try to add an item, what about just showing a running total price in the upper right corner under the shopping cart icon? What about flashing a notification after each added item in the lower right like "Added 12 oranges for $5.68. Order total is $96.78."? What about allowing the user to expand the shopping cart contents from within the shopping path to see what's currently in there? Now that I have some possible solutions, I can circle back with the user, and we can evaluate the best way to solve their problem.
So, why do so many projects seem to have an issue with this? My suspicion is that it's related to the deference that "user requirements" (more on why I hate this term in later weeks) are given in the industry today. The notion is that there are certain "requirements" the system needs to have, and if we want to uncover it, we just ask the users, and eventually they'll tell us what the system "needs" to do. In this case, we have a "feature request" that came directly from a user. It must be a user requirement! We'll add it to the list, and build it. What could go wrong?
We need to avoid mistaking "what the users need to accomplish their goals" and "what the users' best design for the system looks like." Users are not great system designers. That's OK.
Users are really good at feeling pain, and feeling it's absence. Users need to be valued and listened to. User feedback on your application needs to be welcomed and acted on. But that doesn't mean we should blindly expect them to design a software application. Translating from user pain to user goals to effective solutions that allow users to meet their goals is your job and your team's job. Expecting to users to do that translation into solutions for you isn't valuing your users. It's abdicating your responsibility, and hiding behind "Hey, I'm just doing what the users asked me to."