3

At the consultancy I'm from we were encouraged to be "full stack" team players in "self organizing teams". This wasn't just "full stack" in the technical sense (DevOps, automated testing, UX/UI through back-end) but in the business sense too - we coached teams, product owners, gathered high level requirements, led white-boarding sessions, facilitated retrospectives, brown bags, planning meetings, delivered reports, etc.

What additional value does a dedicated BA bring to a lean-process team like this? I may be naive so that's why I ask. Is the BA just required for up-front planning and little ongoing work? This sounds very waterfall-like to me.

2

A full-stack team that includes players capable of understanding business requirements and transform them into a software design and implementation is very effective.

But usually, no one covers every aspect of a complex system and know everything on all the business requirements. For example, someone who has a deep understanding of finance, accounting, financial maths will simply not be as receptive to some physical flows or logistical requirements than someone specialized on production, MRP scheduling or product safety.

And there is where a dedicated BA can help. Maybe he has no implementation role, but he/she should :

  • have a broad understanding of the relations between business needs. He will see links in business requirements that are not obvious for more specialized colleagues. For example that there are several kind of prices the customer may want to follow for a material in warehouse, and that warehousing has also some indirect costs and how to best capture them.
  • as a kind of functional integrator, help to build an architecture and design that puts all these requirements together, eventually helping to sort out conflicting requirements.
  • prevent risk, for example by identify in an early stage missing requirements that from experience are common in business processes in scope.
  • understand the relative importance of different features, and help to prioritize them.
  • most of all, identify business improvement opportunities beyond the current practice of the customer. Or if you have a product that already enables such change, quantify them and promote the change in the customer's business ("sell" the business case and get support from users)
  • speak business language, with upper level stakeholders (the customer's CFO is not interested in the advantage of the ORM layer, but he would be delighted in the decreased maintenance cost that it could help to achieve).

But the key aspect to benefit from a BA, is not to use him/her just upfront (yes: it would be very waterfall oriented) as a kind of planning guru or as producer of some nice studies nobody would read anyway : you have to involve him/her in very close cooperation with the rest of the whole team throughout the project.

| improve this answer | |
  • Thank you. This sounds more like the Product Owner (usually from the client) that I'm familiar with. We try to select someone from the client who can be delegated time and authority to speak on behalf of the business and represent them. This person feeds questions back to the various stakeholders and is the gateway to the team for requirements from the business. – cottsak Aug 2 '16 at 0:42
1

I'm also unsure as to how far the BA needs to be involved in the day-to-day work of such a team. However, the additional value is not listed in anything you mentioned above.

Sometimes, the product owner doubles as the BA, but depending on the domain and that person's experience, this may not be enough. A dedicated business analyst is the most knowledgable person regarding the business domain. Any BA is definitely to be considered a stakeholder and it's just a question on how you add her to your development process - be it as a consultant to the product owner or a regular attendee of sprint planning meetings.

Some of the values that the BA can add could be:

  • Prioritization of features based on their expected revenue
  • Clarification of any domain and financial questions
  • Stakeholder who may introduce new requirements (like features for better analysis of the software's impact on the business)
  • Support for better matching domain workflows/processes to software workflow
| improve this answer | |
  • This validates more what I was thinking. The trigger for my question was a "contractor BA" to be added to a upcoming gig. This is not what you're talking about I think since this person would be coming in green and is not part of the client's business. In this way, I can't see them having any value over such a consulting team. The BA you're referring to is more valuable when they're from the client -- am I right? – cottsak Aug 2 '16 at 0:44
1

It depends a lot what the competencies of team members are and whose interests are at stake. A typical project for us the POs usually represent business interests and while they understand their product and their priorities, they usually try to throw rough ideas at the dev team and ask for everything to be done as fast as possible. The BA or Product Manager is the one who slows their roll and puts their requirements into story form, solicits estimates, ensures Definition of Ready is met before committing and forces the pace to stay sustainable.

If your POs are better aligned with the team, or you have a strong enough scrum master to force the process, then the BA/PDM may be a luxury. In my experience (mostly consulting) we'd get steamrolled without one.

| improve this answer | |
  • That's interesting, as in my experience (consulting too), it's often one of our consulting devs who facilitate all those things you mention. We simply coach the PO into making the decisions. – cottsak Nov 16 '16 at 13:09
  • It's a question of bandwidth I think. A Sr Dev or Tech Lead can do it, but that's time away from doing their core competency. If you have a firehose of stories coming through, it make sense to have a dedicated person to manage it. – jiggy Nov 18 '16 at 20:42
-1

The Idea of a Business Analyst in general is to look at the business, its processes, revenue flow, governance etc and determine where improvements can be made.

When it comes to software creation this can potentially be narrowed down into specific feature requests, ie the software must allow the user to do process X with information Y so the business can reduce staffing in dept Z.

However! in my view, this often doesn't work well in practice.

The day to day process of creating software is pretty far removed from financial/time and motion/governance high level aspects of a business that an analyst would be primarily concerning themselves.

"We don't sell as many item as expected in Germany because they have a weird store card system we don't support"

doesn't translate well into:

"Make the buy button bigger and put in an extra field for expiry date, but only when the IP resolves to Germany or the user has a German address, but hasn't selected the UK language selection drop down"

Also, it will have a host of more 'businessy' concerns such as:

"Hire some German speaking people in credit control and negotiate a deal with a German bank"

All too often you see Project Managers being called BAs and doing their analysis by asking Stakeholders "what colour would you like the button to be".

So my answer is "Yes, The business needs a BA, and No, your agile project doesn't."

| improve this answer | |
  • 1
    Sorry but I didn't really understand your analogy. – cottsak Aug 2 '16 at 0:45
  • there is no analogy? – Ewan Aug 2 '16 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.