Frequently Asked Analysis Questions

Answered by our Experts

As a training company, you can imagine all the questions we get from our students. There are some though that we hear more than others. We’ve compiled a list of these and our experts have documented their best answers.

Questions and Answers

What does a Business Analyst really do?

The question might actually be, what does business analysis really mean? In this rapidly changing, digital, agile world, the business analyst seems to be a role that companies are forgetting or ‘reallocating’. I actually don’t care what you call me, but let me do my analysis and let me help my business succeed! So a BA or a person in the BA role, be it Product Owner, Domain SME, System Analyst, whatever you call them, needs to understand what value good business analysis provides to an organization. The IIBA has a great definition in the BA Body of Knowledge v3.0®: “Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.”

In a nutshell, business analysis is helping the business understand itself, and using that understanding to communicate how to drive to a successful solution that will deliver business value. We help the business help itself. The main job within business analysis is asking A LOT of good questions and then figuring out how to best communicate the answers to the team that will provide the solution. That could be formal documentation, informal documentation, verbal communication, drawings, videos, etc. It all depends on your organization, the product or project you are supporting, the team with which you need to work, and the approach you take (agile vs traditional, for example). It means having a huge skill set: communication (oral and written), negotiation, mediation, prioritization, facilitation (meetings and workshops), patience, empathy, attention to detail, big-picture thinking. The list goes on…our Essential Skills for Business Analysis course can help you understand and address each area of concentration.

Do I really have to scope?

Nope, there is never a need to scope. That pretty much ensures that your project will never end, will have problems, and will cost too much. Should I go on? So obviously I’m saying that YES, YOU DO NEED TO SCOPE! Scope will provide you and the entire team some good stuff:

      • Clear goals and objectives – how do you know what to do if you don’t have clearly articulated direction?
      • Alignment with organizational strategy – if you aren’t tied in to the organization’s vision, then why are you doing this?
      • Innovative thinking – if you really understand the problem or opportunity at hand, you can brainstorm more effectively around solutions.
      • Identification of impacted parties – get the right people involved early!
      • Assists in managing changes – how do you control changes if you don’t have scope to begin with (even on agile projects)?
      • Team building / morale building – if everyone understands the direction and are all rowing in that same direction, you have a better chance of good teamwork!

All of this will help drive to the right solution for your business. Get more on scope: Scope Creep’s Impact on Analysis blog post, Leverage the Context Level Data Flow Diagram Quick Tip and Scope Your Area of Analysis course.

What do you need in order to get a user story ready?

A user story goes through what we at B2T Training call the “4 Rs”: Raw, Rough, Refined, Ready. Let’s go through these four stages and I’ll explain why each is important.

  • Raw: the initial discovery of feature, function, enhancement or defect, often written in the “As a ___, I need to ___ so that I can ___”. It’s the place-holder with no judgement. Why is it important? All ideas deserve a placeholder for a future conversation.
  • Rough: an initial conversation has occurred with the “three amigos” (developer, tester, and product owner). At this point the key points of the conversation are captured in bullet points. This information is used to determine if the story is in scope or out of scope. There should be enough information for a high level estimate.
  • Refined: the story has formal acceptance criteria, examples, models, and any relevant requirement information. The team should be confident in their estimate or refine it as needed. All larger epics/stories are sliced or broken down. See our Advanced Agile User Stories course for a deep dive into prioritizing, estimating, splitting, and organizing your user stories.
  • Ready: the story should have the business and functional analysis “done” in order to be ready for technical design and development. It’s the team that determine what is “just enough” to be able to sprint with that story without delays or confusion due to missing requirements.

Also, the 3 C’s of User Stories will help keep the purpose of the user story in perspective. See our blog post for more on this concept!

This Q&A is an on-going project that we will post questions to frequently. Check back for more answers and/or let us know your question below!

Do you have a questions you would like answered?

Pin It on Pinterest

Share This