Frequently Asked Analysis Questions
Answered by our Experts
What does a Business Analyst really do?
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?
- 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?
- 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 determines 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!
How do I know when I’m 'done'?
- Make sure the business problem is actually understood (and that we have arrived at the root cause or causes)!
- Understand and involve your stakeholders so that you can set expectations on what you need to help make them successful.
- What we elicit, analyze and communicate should give us enough information to support decision-making and help resolve or mediate conflicting opinions in the business.
- What we elicit, analyze and communicate should clearly depict to the business the solution to their problem.
- What we elicit, analyze and communicate should be enough for the technical team or solution developer to effectively and correctly develop the solution.
Working closely with the business and solution or technical stakeholders can help you achieve the right level of analysis! We recommend attending our Essential Skills for Business Analysis for a deeper understanding of how to determine what “just enough” analysis is for your project.
What are T-shaped skills, and why should I develop them?
A person with T-shaped skills has deep knowledge in a specific area, but also possesses knowledge across a range of disciplines.
In teams, a combination of I-shaped and T-shaped skill sets can prove extremely beneficial. For certain highly skilled tasks (think of some really technical areas) you just need someone who is very talented in that area. You don’t need them to strategize, you don’t need them to innovate, you just need them to do that one thing really well.
By contrast, individuals with T-shaped skill sets are often the “glue” that hold teams together. They can reach across boundaries and draw people together. They know enough about other disciplines to understand how the team’s actions will impact other groups. They are able to look at the bigger picture and ensure that the team stays on the right track. Many organizations use this concept in leadership development programs. Leadership candidates work in a variety of jobs across an organization to help them develop this diversity of skills. For more on T-shaped skills and developing a cross-functional team, take a look at Jacqueline’s From a Dysfunctional to Cross-Functional Agile Team blog post.
How do I know I am not missing anything?
This is another reason scoping is an important element to any project. Go back to your scope diagram and make sure that you understand the big chunks, and then as you detail into them, they will help you identify the smaller chunks. It will also help you identify how to test those. Oftentimes, when you’re considering testing your solution, you realize a missed detail that you’re going to have to go back and pull into the project. For more on scoping and managing change, check out Jacqueline’s blog post: Scope Creep’s Impact on Analysis.
Also, having the right people involved is critical; requirements gathering, management, validation, etc. is a team effort. Don’t go it alone; use the resources at your disposal to take a second look and to look at it from their perspective. Someone might even remember something from a previous project. Ali details some more tips on validating your requirements in her blog post.
How do I keep the business from going straight to the solution?
The real thing to think about is how you roll them back. Don’t get frustrated or be immediately dismissive. Accept the solution, but start asking questions to get to the core of the thought process and business need. For example, “You’ve already gone through the thought process, and you have a solution. Help me understand so the team can make sure we’re hitting the mark,” and “What are the overall needs that we have to accomplish?” Get back to the business requirement type stuff. Then, you can make a determination if the solution presented will achieve business value. For more help with understanding business value, get your Business Value Framework in Kathy’s Business Value Framework and a Really Big, Strong Guy blog post.
If you see a disconnect between the need and the proposed solution, start having conversations about maybe changing that solution. This can be hard for a BA, and there will likely be politics involved, so acknowledge their vision and creativity, but don’t be afraid to identify the gaps and validate your recommendation. Also, don’t forget – even though they think they know what they want, they are still coming to you because they need you.