Skip to main content

Author: Raji Pillay

What does a Tech BA ask?

As a Technical Business Analyst, I have at times needed to tweak my approach and templates to create an effective story.

I have found the below templates useful when I am working on a technical story, a defect or a tech spike.

a) Tech Story Questions/Template

As a user/system I want to be able to so that I can

I have found this agile way used universally to be very helpful to give a one line insight into what we are setting out to achieve. As a Tech BA at times I have struggled to frame it in this format. However putting in the effort to word it right brings out the essence of the story. It makes it readable and understandable for tech and non-tech stakeholders. It sets the tone of the story to discuss it in further detail.

Summary of what we are trying to achieve

Elaborating and giving a context around the story gives the audience an idea of why we are trying to achieve this. This can be worked on by answering questions like: What initiated this story? What problem is this story solving? What value is the story adding?

What is the approach we plan to take?

This question is to make the development/tech team brainstorm about how and what needs to be done to achieve the first statement of the story. This conversation is imperative and forms the crux of what and how we will deliver. This should be a free flowing conversation with the tech team and every input should be considered and validated. Even if it looks like it is a development intensive story ensure everyone from the squad is part of the conversation. It ensures that we have covered the story from all angles and we haven’t missed out things from a testing or a non-functional point of view.

What conversations do we need to have and with whom? What skills do we need to complete this?

The above conversation will lay the foundation which will highlight what skills or questions must be answered to complete the story. Do we need more detailed design? Do we need collaboration with downstream teams? Are there any configurations that we need to consider? Is there a skill we need that we do no currently have?

What are the known unknowns in our approach?

(Potential risks and unknowns or blockers expected)

This is an important parameter of the story. Are we working with known unknowns or assumptions or constraints? Does our approach come with any risks that need to be highlighted or escalated or exempted? For example, we are unable to mask all customer data in non-prod, since our automated test cases need customer data. These questions can uncover risks. They shed light whether we need to fix our test suite or what workaround do we need to do with customer data in non-prod.

How can we confirm this is working?

Given <> when <> then <>

This format works best to create testing scenarios for the story. This format in conjunction with the first line of our story gives us a structured format to write tight test cases or acceptance criteria. This should also include non-functional parameters: performance, reliability and security.

Documentation Link (if any)

Yes, it is a good practice to avoid unnecessary documentation. However, in my experience I have seen a few tech stories needing documentation.


How big is this piece of work?

Complexity sizing works best in an agile world. There are numerous methods out there that can be used. Fibonacci series and t-shirt sizing are the most commonly used in my experience and easy to grasp.

b) Defect Story Template:

Current Behaviour –> what happens now

Expected behaviour –> what should be the correct behaviour

Impact–> what is the defect impacting

Steps to reproduce –> Do we know how to reproduce the error? Is the defect environment specific? If we are unable to reproduce in a specific environment, what is the configuration or data difference between the two?

Root cause analysis and Steps to fix should ideally be the output of this story/epic.

c) Tech Spike/POC Template

Do we have multiple approaches?

Tech stories can have varied approaches and the output can be unknown. List down all the approaches and brainstorm them.

What approach are we taking?

As a spike for one sprint consider the approach which seems viable, efficient and the one which is preferred.

Do we need to time box it?

I am an advocate of time boxed POCs. After the end of the time the team can discuss the challenges or issues or wins and then decide if another POC is required.

What are we expecting to see at the end of the POC?

It is crucial to set the expectations of the POC at the beginning. A POC need not turn into a complete implementation. A POC is to uncover the do ability of an approach or the challenges of that approach.

Along with these it helps to keep the INVEST (independent, negotiable, valuable, estimable, small, testable) or SMART (specific, measurable, achievable, relevant, time-boxed) techniques for user story quality in mind. I have always found creating an Independent tech story which can be done in a sprint to be a challenge. However, working with a method gives a structure and similarity to the stories. This is advantageous for the project and everyone on the team gets around to working with it. Having said that method used should work for the team and not against the team.

Superhero powers of a Business Analyst

Captain America: Cap is a great leader, field commander, and tactician. He led the Avengers for a long period of time, and his great experience makes him a seasoned commander on the battlefield.

He also creates the plans for the Avengers and has a great fighting spirit.

Skills: Planning and Monitoring

You need to be able to lead stakeholders. It is imperative for the Business Analyst to understand where we need to go and how we need to reach the end goal. If we need correction along the way, then we need to be able to drive it.

Black Widow: Natasha (Black Widow) has proven herself to be one of the best information gatherers in the Marvel Universe.

Skill: Elicitation

If you have seen Natasha talk to Loki in Avengers 1, you know how efficient she is in deriving information. Isn’t that what a Business Analyst does day in and day out? Elicitation lies at the core of what we do. Being able to drive conversations and collaborations is imperative for the business analyst role.

Dr. Strange: psychic abilities

Skill: To be able to understand what the customer wants based on what he says and doesn’t say

Elicitation is gathering information. We need to be able to see beyond the words, we need to be able to read between the lines, we need to be able to figure out the conflict between stakeholders, we need to be able to understand the problem. This ability to read information which isn’t articulated is really a super power for a Business Analyst.

Vision: superhuman analytical capabilities, and the ability to process information and make calculations with superhuman speed and accuracy.

Skill: Requirements Analysis

Oh well!! What can I say to this? Vision might have been envisioned when his creator saw a Business Analyst at work! One who was making sense out of the information and data at hand, figuring out the jigsaw puzzle to start seeing the pattern. Aren’t we absolutely skilled at this?

Nick Fury: He is a skilled tactician and an experienced leader.

Skills: Requirements Management and Communication

Nick Fury in theory does not have any superpowers. But well he is very good at bringing the team together and putting forth the mission at hand. That is a part of what we do. We should be able to bridge the gap between the problem and the solution by bringing everyone on board as a team. We need to get everyone on the same page. As a Business Analyst we need to resolve issues, try and understand risks, communicate and mitigate them and escalate them when required.


Iron Man: Tony stark is effectively a genius, able to constantly create new and improved technologies and makes upgrade after upgrade to his suit of cybernetic armour.

Skills: Non-functional requirement mindset

Tony stark constantly works on improving his suit and tech. He ensures his tools and toys are top notch, efficient and effective. As a Business Analyst we need to ensure performance, stability, reliability and security are in-built into our solutions. That’s what makes our solutions as good as Tony’s suits. We need to continuously be mindful of these parameters.

Thor: Is strong even without his hammer

Skill: No dependency on tools

Thor is god and his hammer makes him invincible. But he is powerful even without his hammer. Yes, we need tools to make our lives easier and smarter. But we should be able to adapt to new tools changing according to projects/organizations and still be the best Business Analyst we can be. We should be able to tap into our Business Analyst skill set irrespective of the tools.

Quicksilver: superhuman agility to move at great speeds

Skill: Being able to adapt to change

He might be a bit too fast!!! But it is our ability to incorporate changes to requirements at quick speed that can make us extremely effective. Agility is the way to go in today’s technologically disruptive environments.

Black Panther: ability to access the knowledge and experiences possessed by previous Wakandan kings/queens.

Skills: Learn from existing knowledge of mentors, books, articles; reach out to people in your organization or outside

Avoid re-inventing the wheel. There are methodologies, processes, formulae that people use across the spectrum that we can re-use. Don’t work in a silo, reach out. There is a sea of information and tools available that can help us in our journey in projects, utilize them. Ask: if you need help with a problem.

Collaborate: It makes for efficient and effective solutions.

Batman: Batman does not possess any superpowers; rather, he relies on his genius intellect, physical prowess, martial arts abilities, detective skills, science and technology, vast wealth, intimidation, and indomitable will.

Skill: Underlying competencies

We all are unique in our own ways. We have varied experiences, skill sets, strengths and weaknesses that we utilize for the success of the project. We run into problems and we try and reach a solution based on our own mental make-up. This is what sets us apart and brings in our unique value.

Being your own self is the key to enjoy playing your role. There are challenges we face in every role and project, being able to come back to our own self is powerful, being fully aware of our strengths and weaknesses is powerful, having a growth mindset is powerful.

What other super powers do you think a Business Analyst has?

Business Analyst in the Cloud

Nothing is up there. In the past I have looked up involuntarily when people have talked about cloud.

Cloud is essentially a datacentre. It provides access to shared and configurable resources via the internet. It allows organizations to not worry about the underlying infrastructure and focus on the value they can provide to customers by rolling out applications and services. 

Why is everyone going bonkers about moving to cloud? Security, reliability, scalability, performance, cost optimization and the works make it so viable.

Having worked in Operations I have immense respect for these features and the value add it provides to the organization and its customers.

If Cloud is a datacentre, what makes it different?

  Traditional data centre Cloud
Security Security is shared responsibility. Whether it is traditional on premise infrastructure or Cloud there needs to be a balance between security of the infrastructure and the data or the application. Security is shared responsibility. Whether it is traditional on premise infrastructure or Cloud there needs to be a balance between security of the infrastructure and the data or the application.
Reliability If you have good monitoring in place, you will get alerted to any issue with your servers. You will either divert traffic to your DR site or take an outage while you fix the issue.
And if a replacement is required from your vendor, then you add to your outage window.
Manual work involved is high. So is pressure.
If any of your instances is unhealthy, another instance is spun up automatically. Work continues as usual.
No manual intervention required.
Performance It is a busy time for your business and traffic to your application is going beyond usual. If your instances cannot handle the traffic, adding more CPU for example will require hours and hours of wait before your vendor can provision it after all the processes and approvals are done.
During this time, your customers are impacted and it is not what we strive for.
Your application can scale automatically to cater for increasing traffic and when the traffic normalizes it can scale down.
No manual intervention required.
Cost Optimization Basis the performance example, you have added more instances to cater for increased traffic and now you are paying for it even though you don’t need it after the traffic has normalized. Pay as you go.
Since your instances scale up and down in direct proportion to traffic you only pay for what you need.
If your non-prod environments are not used 24X7, shut them down after-hours which can be a huge cost benefit.
Delivering to market Implementing a new idea, would mean guesstimating the required infrastructure and acquiring it. If the idea doesn’t work, you will be left with infrastructure you do not need.
Also acquiring infrastructure would mean – process, time and pay.
You can quickly deploy your idea to cloud to validate its use.
Once you roll back you are no more paying for the infrastructure. This enables us to fail fast and learn.
Staying relevant and competitive Release to market takes longer and is cumbersome process.

You get higher control of your environments which translates into faster turnaround times.

Start-ups are enabled by cloud technology.
A new idea can be rolled out as beta in months and new versions can be shipped to market in a competitive time frame.


All of this and more can be enabled by cloud computing. However, it is worth noting it is up to us to design our applications to make full use of the services and features of Cloud. The onus is still on us to deliver world class applications. Cloud enables us to achieve that goal seamlessly.

Lifting a crappy application and shifting it to the Cloud will not provide any advantage. That is where we can step in and drive the conversations.

How does a Business Analyst play a role?

All the above benefits of cloud technology can only be leveraged if the application is designed to incorporate all the cool features that cloud can provide.

The questions to ask:

  • Have we considered security in the cloud?
  • Have we designed the application to be highly available, making use of multiple availability zones and regions offered by cloud?
  • Have we catered for reliability?
  • Have we ensured our infrastructure is scalable?
  • Have we made use of CDN (Content Delivery Network)?
  • Have we made use of tools for logging and monitoring to be proactive?
  • Have we made use of cloud features that make our applications easy to run and use?
  • Are we still building monoliths?

If you observe, the questions that we need to consider are not very different in the Cloud. However, we can get these features implemented with ease within short time frames.

Over years these features have taken a backseat only because of the time and effort required to roll it out along with the functional requirements. Cloud has now made it easier to implement. As a Business Analyst now we can incorporate these as features or acceptance criteria. We can lead the way where we ensure non-functional requirements are the pillars for functional requirements and they are not mutually exclusive. We can educate ourselves and others as to how Cloud makes it easy for the business to achieve these.

If you are new to Cloud and learning a new technology seems daunting:

  • Understand the concept of cloud computing.
  • The features that it provides
  • Doesn’t matter whether you pick Azure, AWS, Google cloud platform
  • Pick one and understand the basics via millions of courses available
  • Few lectures in and your fear will start dissipating

Let curiosity drive you!!!

5 Steps to Prevent that Overwhelmed Feeling

There are numerous reasons to get overwhelmed as a Business Analyst in a project. The requirements aren’t shaping up; there is no vision for the product and the solution design isn’t complete. As a Technical BA, you are anxious about starting.

And so it continues…

In a utopian world, everyone is on the same page, stakeholders have their vision organized, and all a BA has to do is, understand it, articulate it and help deliver it.

Easy-peasy!!! If only this were true in the real world.

On certain projects, I have felt overwhelmed and at a loss on simply where to start and what are the milestones we are planning to achieve. At times, it feels the project will never start or worse, it will never end. Also, after discussing this with fellow BA’s I have concluded: I am not the only one.

Captured here are the 5 mantras I now follow, and they have helped me secure my footing in the world of projects:

  1. “Converse and Collaborate”: I believe it is one of the core requirements of being a BA. It is the crux of what we do. It is critical to make a start, to gather and collate information, to facilitate, to start making sense. First and foremost start talking to the entire spectrum of stakeholders: business, end-users, architects, implementers, testers, security. Even if the dots don’t connect, keep these conversations and collaborations flowing. These conversations need to be frequent at the start of the project and then they can be scheduled as required. Yes, a BA needs to have the conversations with the stakeholders but equally important is all the stakeholders coming together and brainstorming. Get your business and users together to brainstorm requirements, understand what they need, what is the vision, what end user problem are they trying to solve with this requirement. Once that is underway, get the technical team in workshops, either you can be the product owner or have someone from business play the role. Again, these workshops should be conducted as often as it is required for the design to start taking shape.
  2. “Break it down and Bring it together”: Even if the information is not lining up and seems absolutely haphazard, record it. If there is no structure at the beginning, don’t fret. It will start taking shape. The roadmap will start showing itself through these conversations and information. Different categories will emerge out of the information, which at the beginning may seem random. Break down your requirements into manageable/understandable pieces of work. In an agile world, you start splitting them into epics. Categorize the pieces based on a theme. The theme in turn, can be based on a roadmap, milestone, functionality, menu of the application, the infrastructure it lives on, so on and so forth. When you pick up a bite sized piece of requirement, analyse it with developers, quality, performance testers, security architects, operations and DevOps. It doesn’t have to be a detailed design at this point. But the various perspectives will start shedding light on the details, unknowns and the risks. This will start bringing the variables on a requirement together.
  3. “Step in and Step back”: Facilitating conversations is imperative. Have an agenda and communicate the same before you bring the stakeholders together. As a Business Analyst, step in to ensure the conversations are flowing in a way to achieve the expected outcome of the meeting. At times, the conversation drifts towards a topic/constraint/feature that no one anticipated. Let it continue. These inputs uncover a can of worms that was not thought about originally. It adds a different dimension to the requirement that needs more work. Stepping back during technical conversations allows the team to brainstorm solutions, uncover unanticipated blockers or just a different approach to achieve the solution.
  4. “Revisit and Revise”: The requirements have started to make sense but the requirements might change; technically the requirement might not be doable, you might run into licensing issues, a feature might take longer than anticipated, third party constraints might pop up, a functionality would now be considered “good to have” instead of “must have”. Revisit your epics/roadmap and adjust.
  5. “Validate and Verify”: You don’t want the technical teams to be designing a beautiful solution that doesn’t solve the given problem. Keep validating your requirements, keep verifying the solution. Acceptance criteria, the definition of done and test strategy at the beginning of the SDLC will help in achieving the right goals efficiently. These need to be continuously validated by the business. The product owner or the business from where the requirements originate need to be kept in the loop. I strongly advocate for the business to be involved during the development lifecycle. Issues or changes can be caught before they become critical or un-manageable.


pillay 08092018Every Business Analyst has her/his own strategy that works. These steps have been my go to when I feel overwhelmed. Whether it is a small requirement or a program of work, I take one step at a time and the progress comes with it.

What is your strategy?

The DevOps Business Analyst Conundrum

Them: What do you do?

Me: I am a Business Analyst with DevOps

Them: Huh?

Them: How does that work? Who are your stakeholders? What exactly do you do?


This is a typical conversation I end up having every time I mention my role.

Let me start by answering a few questions that I have been posed with over my term as a “Business Analyst in DevOps”.

What is the role of DevOps in Delivery?

DevOps is anything but a buzzword. The term has picked up a lot of attention in technology and for the right reasons.

DevOps bridges the gap between teams that have worked in silos in the SDLC. Continuous Integration and Continuous Delivery enhances Agile delivery model. This allows delivery to ship code in smaller chunks continuously. It accelerates the shipment of code to production.

Some examples that I have worked with in DevOps:

  • Architecture changes/upgrades as part of delivery (eg: upgrading your out of support SMTP server)
  • Implementation of new tools to aid in delivery (eg: monitoring tools like Splunk, appdynamics, use of jenkins)
  • Supporting the non-prod environment
  • Designing deployment pipelines
  • Integrating early testing in the pipeline
  • Delivering robust features

And most importantly cultivating the DevOps mindset across delivery and operations!

Yes, tools are important to achieve the end goal, but we cannot progress without an inherent cultural shift.

Who are the stakeholders for a BA in DevOps and What does a Business Analyst need to consider?

Higher management, delivery team, testing team, operations, and your own self: they are all your stakeholders. The idea or requirement to improve the development, delivery, testing or operation of the application can come from anyone.

The essential core role of a Business Analyst doesn’t change with projects or genre of requirements. The same applies to a Business Analyst in DevOps. The below examples will shed light on projects that BA’s have to work with where the DevOps tools and mindset is required.

a) One-click deployment: This requirement came out of the extensively manual deployments we had to perform as a team. This meant constant monitoring and having someone manually go from one step to the other. Like any other process, the less the manual intervention the less the chances of human mistakes.


  • Operations team (Actual Deployment team)
  • DevOps Team (Creating the one-click pipeline0
  • Delivery team (to provide inputs)
  • Senior Management

Things to consider as a Business Analyst:

  • Understand the issues in current state that the operations team are facing.
  • The ripple effects and the issues this creates for the releases.
  • The advantage delivery team will have going forward.
  • How can this be built to add automated testing and blue/green deployment as an iterative approach?
  • What tools will be required to deliver


b) Migration to cloud: With the sweep of infrastructure migration to cloud, this is a prevalent project in many organizations. Rightly so! The migration can be small-scale lift and shift with only the APIs or queue endpoints in the cloud, or it can be a large-scale migration.


  • Management (the directive and timelines come from them)
  • Solution Architects ( The solution and design will come from this group)
  • Project Managers
  • Performance Team
  • Functional Testing
  • Security Team
  • Database Administrators
  • DevOps
  • Delivery
  • Operations
  • Third Party Vendors if any

Things to consider as a Business Analyst:

  • Work with the solution designers and business to understand the use cases
  • Start creating epics to manage scope and prioritize
  • Break down the high-level design or epic into smaller chunks of work with the delivery teams
  • Incorporate security and Non-Functional Requirements as part of the use cases being delivered
  • Work on data migration strategy
  • Work with Testing teams to create functional and regression testing plan
  • Engage relevant stakeholders to work out operational readiness, DR strategy, and final cut-over strategy

c) Business Requirement (feature/functional driven work): Delivery of a business functional requirement. This piece of work involves as much a DevOps mindset as the above-mentioned work. In the delivery of features, we need to consider the BAU support required for the non-prod environments, the work involving the deployment of the code, the delivery of non-functional requirements. All this done with the “I am not working in silo” mindset makes it as much DevOps as any other work.

This is a snapshot of the things that a Business Analyst needs to consider. It is not an exhaustive list.

What skills does a BA need to be a part of DevOps?

A Business Analyst needs all the tools from his/her toolkit and experience gained over the past to navigate the DevOps world. However the most important is the mindset for continuous delivery, integration, continuous deployment and a keen understanding and importance for the non-functional requirements.

Whether it is in a titled “DevOps” team or a feature delivery team, this mindset will ensure we consider “Reliability” “Performance” “Security” and “Stability” as a feature instead of nice-to-haves.

The role of a BA is then to help deliver world-class platforms, as always.

The core of being a Business Analyst doesn’t change weather we work with a traditional waterfall methodology, an Agile framework or an Agile DevOps framework. In fact, a DevOps mindset is required in any of the frameworks that we work with. It is essentially considering NFRs as a feature and delivering them continuously in collaboration and continuously along with the functional business requirements.

I hope this helps answer the Business Analyst in DevOps conundrum.