6

I work at a company that wants to be agile, but the business analysts often provide us "user stories" that are more solution than problem statement. This makes it difficult to make good design decisions, or in more extreme cases, leaves few design decisions to be made. It does not help the programmers understand the user's needs or make better design decisions in the future. Our product owner makes an effort to provide us with problem statements, but we still sometimes get solution statements, and that tends toward a "code monkey" situation.

An additional challenge is that some (not all) of my teammates do not see a problem with this, and some of them honestly want to be told what to do. Thus, when we receive a solution statement on our backlog, they are eager to jump right in and work on it.

I believe that as a software engineer part of my job is to understand the user's needs so that I can build the right thing for the user. However, within our organization structure, I have zero contact with the user. What kind of things can I do to better understand our users?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Kazark
  • 1,810
  • 1
  • 17
  • 37
  • I hope this question is not too soft. The problem is large and I'm not sure where to start. – Kazark Mar 04 '14 at 22:33
  • As an aside, I've often seen the "given a particular solution from the business rather than the problem" at multiple companies. It isn't the *users* that are the problem here, but rather the goal owner (or is it donor?) and the structure (you should be getting enough information from the analysts... in an ideal world). –  Mar 04 '14 at 22:43
  • 1
    @MichaelT Agreed. The users are not the problem. The problem is that the company structure obscures them from our view. – Kazark Mar 04 '14 at 22:45
  • 2
    Become a user for a period of time. You'll have a list of the most aggravating bugs in about a week. – Gilbert Le Blanc Mar 04 '14 at 23:42
  • 3
    Better than becoming a user, spend a month on the help desk. – mattnz Mar 05 '14 at 00:27
  • recommended reading: [Where to start](http://meta.programmers.stackexchange.com/a/6367/31260) – gnat Mar 05 '14 at 07:28
  • 1
    So basically you want to go sit in the chair of the business analyst? Become one? And then make user stories....you know where I'm going? – Pieter B Mar 05 '14 at 07:40

2 Answers2

3

This really depends on your management.

What I have found in over 13 years of software engineering is that I need to talk directly to the customers and sometimes even end users (often in software these are separate entities). Business analysts are hit or miss: some of them understand the customer and end users and write really good requirements (not solutions), some of them go too far and assume too much.

I would recommend talking to your management and argue that you need to be involved earlier in the process, ideally right after sales exits the picture and the BAs enter. Do not be just a fly on the wall: you need to assert yourself as a product expert seeking to understand the problem domain (ugh, buzzwords: you know your software, you want to learn what the customer wants you to do with it).

For existing projects, I would work through your project manager and try to cut the BAs out of the picture. You will likely get answers that match what you have already been told. Do not accept this. Try to get in meetings with the customer to discuss requirements. In an Agile environment there should be no problem with this: if you do not understand something, the customer is the final arbiter for requirements (but not necessarily for what your company will authorize you to do in the billable hours paid for).

Essentially, keep asking questions and do not shut your mouth until you fully understand what the customer wants. Just because a BA gave you an odd-sounding requirement does not mean this is what the customer wants, or that it is the best way to accomplish the customer's wishes.

  • 2
    Note: I've seen people loose their jobs for trying to understand the big picture for too long rather than deliver cards to a spec. You need to understand that every time you question a user story written by somebody you undermine their competence and that's human relations, not engineering. – tymtam Nov 15 '16 at 00:42
  • @mayu I specifically mentioned being involved early in the project, implying before there are specific requirements to deliver in an iteration. Furthermore, even during an Agile project, there should be built-in downtime for retrospection of previous iterations and clarification for future iterations. –  Nov 15 '16 at 20:05
2

Direct and honest communication between the development team and all stakeholders is the only reliable way of delivering great solutions that I know of.

This is damn hard to organise and organisations take shortcuts with product owners, project managers, program managers, subject matter experts that can give the dev team some time from time to time. I believe that the role with the most impact is the product owner.

Pragmatically speaking I would suggest that you choose a pet feature and make it the best you can - if it works out, you may get a bigger feature to work on and the success of the first feature would give you more leverage in discussions how to do things.

If you want plenty of opinion about this issue ask at workplace.stackexchange.com.

tymtam
  • 1,703
  • 2
  • 11
  • 11