A really enterprising individual got in touch with me a few weeks ago to help him understand the role of a Business Analyst, especially in the context of ThoughtWorks. He sent across a list of questions and I am posting them here along with my responses in the hope that other's might also find this helpful.
About me: In case you were wondering why he felt I would be able to answer his questions :-). I have been playing the role of a Business Analyst in multiple client engagements over the last 12+ years. Here is a link to my profile for more context.
What was your typical day like when you started as a Business Analyst in ThoughtWorks?
My typical day starts with preparing the physical story wall for my project, so that when the team sign’s up for the tasks for the day there are stack ranked story cards for them to address.
Then, we have the standup and team sign ups where the team shares any blockers they faced or are facing on their stories and any key lessons they picked up. If I have done a good job of explaining the business context of the stories in the backlog then the team sign-ups tends to be smooth and the team is able to sign-up for stories/tasks without much direction from my end.
You will notice that most of the activities are focussed at ensuring that we catch any issues upfront rather than later in the cycle, since the later they get caught the more costly it is to fix them, thereby accumulating waste which we want to limit as much as we can. The activities below occur on a daily basis in my world:
- Story kick-offs - When a dev pair (we follow pair programming in all our projects) picks up a new story for development it is my role to ensure that the pair understands the business context of the story and use as many visual means (workflows, wireframes, diagrams) as possible to ensure that this process is smooth. The quality analysts and feature owners (if any) are also mandatory participants in this activity. Generally, we invest around 15-20 mins in this activity for each story.
- BA volleyball - Once a dev pair has completed a story from their end we conduct a BA volleyball which is essentially a validation exercise where the same individuals what kicked off the story come together and we run though the main acceptance criteria of the story. If we observe any issues of bugs then the feedback is passed right there to the dev pair who work on resolving this issue before the QA’s can pick it up for automation testing.
- Backlog grooming - Another continuous task for me is to ensure that the feature/story backlog is analysed and detailed enough to provide uninterrupted work for the dev pairs. I generally work 2 iterations ahead of the dev pairs and consciously avoid going more in the future since business priorities are ever evolving and I don’t want to focus my effort on something that might get de-prioritised.
- Team huddles - Since we do not perform low level design of our applications upfront, the team gets into quick (15-20 min) huddles next to the work area to discuss problems and agree on a common direction, my role in these discussions would be to provide business context and also answer any business related queries. I would excuse myself (or be excused) if the discussion is purely technical, this is decided on a case to case basis.
- Customer interaction - I have daily catchups with my client counterpart, which is either a person in the role of a Business Analyst, Product Manager or direct user. These sessions are used to analyse the next set of features, continuously prioritise the backlog by evaluating/re-evaluating the value of a feature/story, and asking any open questions that may have popped up from the team or during my own analysis. We also use these sessions to review the stories that have been detailed by us to that we can get a sign-off and incorporate the feedback (if any)
I also get involved in the below activities but these may not occur as often as the ones above.
- Prioritization & Business Context - I use the Iteration Planning Meetings (IPM) to ensure that the team understand the current state of the project and the next level or priorities. I also use this session to ensure that the team understands the business context of the upcoming stories. I generally own and drive this meeting.
- Showcases - Ideally, we should be showcasing each story directly to the main user group as and when they get developed, however, owing to the distributed setup that we tend to work in or unavailability of business teams from their regular activities we plan for these at the end of the showcase. It is my responsibility to ensure that we have the right audience for the showcase and the team follows a structured approach to the showcase. The actual showcase is run by the individual team members through volunteered signups, 1-2 folks from the team sign up for each showcase.
- Retrospectives - This is again a shared responsibility but as a BA I take it upon myself to calling out when we have slipped up on this activity. The idea of this meeting is to have an open conversation about the areas of improvement and those actually going well so that we can improve as a group. You can learn more about retrospectives here.
What are the typical deliverables as a B.A?
The following become the key deliverables that come as part of my job:
- User stories - Well analysed, with as many visual representations as possible and well rounded AC’s. Ideally these should always be peer reviewed if you have another BA on the team, you can refer to some tips on pairing for BA’s here.
- Feature overview - I generally create a powerpoint deck or mindmap when I get into discussions with the business stakeholders to get more details on the next set of features to be picked up. This becomes a document of reference as we build on the feature and again having visual representations on this is key for structured discussions with business stakeholders.
- IPM/Showcase decks - When having iteration planning meetings or showcases with the customers I generally use a deck and this again becomes an important deliverable.
What do you love and hate(if any) most about your job?
- Interacting with customers and solving the complex problems that they throw at us.
- To break down complex problems and present them in an easy to understand language/format.
- Getting to dab into multiple business domains and understanding the modus operandi of different companies/business processes.
- Working with high performing teams and watching people grow in their careers, and if I have a small contribution in their evolution then I am even more thrilled.
- Being challenged by co-workers and them setting the bar higher for me on a continuous basis.
When the project comes to the end of its lifecycle and the complex problems tend to come by once in awhile.
Is it necessary that you know enterprise applications to be able to offer a solution to a problem? Or do you get help from others? Who?
Generally, the enterprise applications exist to support business processes, in my discussions with business stakeholders I try to focus my questions on the business processes rather than the systems. However, if I need to understand the enterprise systems since they are intrinsic to me solving the problem then I would get into understanding the system using the following approach:
- I would use the help from the key SME who knows about the system and then sit with them to get an overview.
- I would also get myself access to a test environment where I can play around different scenarios to build my understanding.
- I would document my questions and then approach the SME for answers.
I was wondering, what books, articles or courses helped you the most in preparing to be a Business Analyst?(I've already read BABOK 2.0, and many articles online)
I think the general lessons I learnt in my MBA helped me a lot in understanding business contexts and keeping my focus in that area. Apart from this, I would recommend a few books which would hopefully help provoke some thoughts:
- The Goal - I really liked this book since it explains a lot of important concepts of how work should flow in a very lucid manner.
- The Phoenix Project - This is similar to 'the goal' but deals with concepts in the IT world and explains how a well-oiled IT set-up should look like for large enterprises, again explained in a very fun novel-like format.
- Crucial Conversations Tools for Talking When Stakes Are High - This book has helped me deal with conversations both in the personal and professional space. I recommend it to everyone! As a BA you are expected to keep the team and the customer in good humor and some of the tips in this book, practised over a period of time, will really help you deal with difficult situations.
- Lean start-up - Developing new products or enhancing existing ones is becoming very different now and this books explains the techniques Product Managers are using to make decisions. It's important to understand this because as a BA you will be working closely with client Product managers or even in some situations playing the role of a product manager in the absence of one.
What type of work samples or portfolio should I be trying to develop as I try to move into this career?
Areas where you are solving complex business problems by using a mixture of systems and human thinking should help you make a case for moving into this career.
What kind of exercises would you recommend that I can engage to better practice being a B.A?
Solving case studies that look to improve the business process for an organisation could help, also, presenting such case studies and their solutions in an easy to understand format will also help.
In a case study for a Business Analyst, what is usually being asked as a deliverable?
This is what I would look for:
- Ability to ask questions to understand the complete breadth of the problem. (Who are your customers, how will you reach out to them, what is your revenue model, what is your differentiator, what is your budget, what backend systems/operations have you put in place, how soon do you want this to happen, what is the state of your current IT systems, how did you do this so far etc.)
- Based on the above the ability to break down the problem so that everyone is on the same page (draw it out or bring clarity in your speech)
- Provide a realistic solution or options based on the inputs you have received and also the ability to think on your feet it you see any constraints.
The solution is not the most important thing that is being judged, the structured approach that was taken to reach till the solution is generally the clincher.
Is it necessary for me to learn Agile if I want to be a B.A in ThoughtWorks?
You need to understand the essence of agile, but it is not important for you to be a seasoned practitioner, we understand that agile practices differ across various organisations and you will undergo training programs once you join to help you understand our brand of agile.
I'll just share my thoughts on how the role has evolved for me over the last few years and what I believe this role is about:
- Central force - In my view, a Business Analyst invariably tends to be the central force around whom the team revolves, and in self organizing teams they could also double up as a Project Manager, this means that you need to be on the top of you game at all times. You need to understand not only the stories and backlog but also be the one that can push the team in the right direction when the focus wavers, you need to take ownership when you feel that we are not continuously improving.
- Build a Self organizing, high performing team - If you are going to achieve a team goal it is important that there is collective ownership in the team and you need to ensure that the team members are continuously enhancing their skills. This requires you to set clear goals for folks on your team and helping them work through their feedback.
- Make yourself redundant - As a seasoned BA on a team I see my role as making myself redundant, which means that I am mentoring other BAs to take on the higher responsibilities and improving themselves. This is the only way I have figured out that I am going to elevate my learning and growth curve.
- Continue to learn - This is definitely cliched so I am not going to spend a lot of time one it but mention it here since this is the only way to remain relevant. I wish I could do better at this everyday!