Tag: Techniques


50 Most Dangerous Words for Business Analysts

As business analysts, it’s our primary responsibility to bring clarity to requirements communication. Unfortunately, many words spoken by our stakeholders can be ambiguous. Not understanding these words in their proper context or without adequate information can lead to situations where different stakeholders can have a different understanding of the same word.

One of my very favorite words is Manage. Manage can mean anything under the sun to anyone. For example, managing a schedule to me means creating a schedule, viewing schedule, updating schedule, deleting schedule, importing schedule, exporting schedule, reporting on schedule, and alerting schedule delays. For the developer in my team, managing a schedule could simply mean creating a schedule, viewing the schedule, updating the schedule, and deleting the schedule (The four fundamental operations on data).

Discussing the ambiguous terms with stakeholders will give them the idea that something is also missing from their end. They can do some more research to find how exactly they want the system to behave rather than giving information that is at a higher level. In this blog, I am writing down the top 50 ambiguous words I came across as a business analyst. I want all my business analyst friends to contribute to this list so that we can comprehensively list the ambiguous words.

Any time any of our stakeholders use these words, we would know that there is some ambiguity involved. It’s not that the ambiguity is always bad, but it must be clarified before something goes for designing and development. So till the time we are far away from that, it’s ok, but as we come closer to the design and development phase, we must find the real concrete information so that the development team can design the solution as per the stakeholder requirements.




Rank The word What makes it dangerous
50 Most appropriate Who decides what’s most appropriate?
49 As soon as possible In the next 5 seconds?
48 In future By EoD Tomorrow?
47 ETC Missing details
46 TBD When?
45 Usually Where is the unusual stuff?
44 Generally Non-precise
43 Normally Non-precise
42 To the greatest extent Who decides the extent?
41 Properly Non-precise
40 Where practicable Conditions not specified
39 Supported Passive voice, Actor unknown
38 Handled Passive voice, Actor unknown
37 Processed Passive voice, Actor unknown
36 Rejected Passive voice, Actor unknown
35 Always Assumed certainty which does not exist
34 Never Assumed certainty which does not exist
33 All Assumed certainty which does not exist
32 None Assumed certainty which does not exist
31 Every Assumed certainty which does not exist
30 Earliest Non-precise
29 Latest Non-precise
28 Highest Non-precise
27 Fastest Non-precise
26 Flexible Non-precise
25 Modular Non-precise
24 Efficient Non-precise
23 Adequate Non-precise
22 Minimum required Minimum shall be achieved
21 Minimum acceptable Minimum shall be achieved
20 Better Non-precise
19 Higher Non-precise
18 Faster Non-precise
17 Less Non-precise
16 Slower Non-precise
15 Infrequent Non-precise
14 To the extent specified Non-precise
13 To the extent required Non-precise
12 Very high Non-precise
11 Very low Non-precise
10 Fantastic What is Fantastic?
9 Multiple currencies Which currencies?
8 Multiple languages Which languages?
7 Multiple browsers Which browsers? Even for the same browser, which versions?
6 Robust Non-precise
5 Sturdy Non-precise
4 User-friendly Non-precise
3 Great performance How do you determine that?
2 User All users or specific types of users?
1 Manage Possibly the most dangerous verb – Can mean anything under the sun

What other words would you like to add to the above list?

The Story Behind User Stories

Starting off my new role as a Business Analyst, I have had a week-long refresher course on the ‘right’ way to write User Stories.

‘Right’ in quotes, because there really is no right or wrong way to write a User Story. All you have are a set of guidelines and common practices, all of which are only tried and true methods as experienced by your peers.

A User Story is somewhat of an enigma. Primarily, it is meant to be a way to communicate requirements to developers so that they know what to build.

However, at the same time, User Stories must also express to the business why this feature is being built and what business value it promises to deliver.

The fact that a User Story has two sets of very different audiences, one technical and the other (most probably) profit/business oriented is what adds to the complexity. It’s like trying to write a novel for both sci-fi geeks and C-suite executives.

What I was reminded of this week was that a User Story must tell the narrative about a particular user behaviour with the product. It is a story in three parts:

  1. Who the user is
  2. What they’re doing
  3. Why they’re doing it


I like that we conceptualize these artifacts as ‘stories’ since stories are usually associated with the ‘why’ behind human behaviour. Journalists seek out motivations behind the humans in their news items in order to make their story richer and more compelling.

That third part, the ‘why’, is important not only because it is the red string that allows both the tech-savvy developer and the business-minded executive to agree on a universal goal that the User Story is trying to achieve, but it also provides the reasoning as to why the user will behave in that particular way.

The ‘why’ is always written from the point of view of the user. The ‘why’ is never “to increase profits by 20% in the next quarter” or “to save on annual storage costs”.

The ‘why’ always focuses on serving the user.

The ‘why’ can also influence design decisions. Does this User Story have the purpose of entertaining a user or is it intended to make their life more convenient? This may be the difference between creating a simple button or having a dancing hippo pop up on your screen.

When we are in the early stages of building a product, we are focused on all the things that a user will be able to do with it. We go wild with our imaginations and that’s perfectly OK.

But with every user behaviour, we need to ask ‘why’. Why would the user want to do that? How does that behaviour impact their lives? How will this feature serve the user?

Once we start asking ‘why’, then we’ll create products with more impact. Because then, behind each user action lies a great story.

5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest. 

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’. 

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.


3. Creating an information vacuum, allowing gossip 

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups. 

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation. 

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

Are You Suffering from Agile Fever?

Have you ever come across a colleague or a family member who has a knack for making every conversation about them?

Do you have people in your social circle who influence every group decision to their benefit? Of course you do! When describing these people we typically say “You know the whole world revolves around Joe!” Do we really enjoy spending time with these people? Of course we don’t because they are exhausting and frustrating to work with. Well let me tell you something, these people have a lot in common with user stories. The user story has become the center of the Agile world. Everything in Agile seems to revolve around the user story. They have become exhausting and frustrating to work with for many of us. How did we allow this to happen? How did the Agile community get to choose the technique we must use to convey the requirements for a solution? The BABOK details numerous techniques that BA’s can master for the purpose of eliciting business needs, determining “wants” from true “needs” and communicating the actual requirements which must be met. Why is the user story being elevated in importance over all other techniques? I have personal experience in “Agile” organizations who are absolutely obsessed with the user story. I’ve also been fortunate enough to meet many of my BA colleagues at conferences who have the same frustration. Why do we seem to be limiting ourselves or over relying on this one technique?

Mike Cohn of Mountain Goat Software is regularly credited with coming up with the format of a user story. I’m sure we’re all familiar by now with the “As a _____, I want to _____ so that I can _____.” format. By no means do I intend to discredit this format or this technique. It can be valuable in the right situation.

However I view the user story as a singular tool within our BA tool belt. One single tool should not be the center of any development methodology. Unfortunately I’ve come across some development colleagues who are infected with Agile fever. Agile fever causes the temporary loss of common sense and logic and is characterized by an irresistible desire to adhere to an irrationally dogmatic process. Those infected with Agile fever latched onto the user story as the center of their world since it seemed to have lots of potential. It has a simple format and it seems that anyone can write them. With the user story as the center of the universe time consuming business analysis could be eliminated and replaced with simple user stories and conversation! What a eureka moment this must have been in the Agile community. I can imagine the crazy celebrations which must have ensued. As many of us are learning this is not necessarily working out as planned. Some organizations that tried to eliminate BA’s or relied entirely on the conversation generated from user stories learned that Agile fever can have serious consequences to their business.


So what does Agile fever look like and how can you tell if your team may be infected? Let me give you some examples. A developer once explained to me that he understood the requirements and knew exactly what we were doing and why. However he demanded that the requirements be reworded into the typical user story format because our group was “Agile”. Agile fever was infecting him to the point that he could not function unless the user story became the center of his world. Once the requirements were rewritten he instantly calmed down and was able to function once again! If project team members are demanding requirement rework so you can be “Agile” then you’re likely infected. Agile fever can also cause Goldilocks paralysis. If you’re not familiar with Goldilocks it is the story about a little girl who wanders into a home occupied by three bears. While in the house she tries out three chairs exclaiming “This chair is too big! This chair is too small! And this chair is just right!” I must warn you that Goldilocks paralysis is extremely contagious and can infect entire project teams very quickly. It is characterized by project teams that spend significant time arguing over the size of the user story. You’ll hear comments such as “That story is too big! That story is too small! “We need to break these stories down” or “This story doesn’t fit in our sprint”. As a BA if you notice teams arguing over the size of a story and wasting significant time over it then be aware that they are infected with Goldilocks paralysis. It is treatable with an injection of common sense and reason but it may take a while to take effect depending on how high their Agile fever is.

So what do I suggest we do as BA’s to counteract this over reliance on the user story? I propose that we remember that the word “analysis” is in our job title. Therefore we must never forget that great analysis is what our methodology should revolve around not a single technique. Don’t let anyone influence you away from using other techniques. Great BA’s utilize the right tool or the right technique at the right time to uncover the business needs that will drive business value. The user story is one way to convey that information but it does not need to strictly adhere to the standard format. I have successfully used fully dressed use cases (Oh my!) on a project since they happened to be the best way to convey the requirements for that particular project. Don’t be afraid to think differently and convey the requirements in what may seem to be an unconventional way because it doesn’t fit into the Agile prescription. Drawing a picture, creating a wireframe or using some other visual technique will drive conversation much better than a standard user story. Do some stakeholder analysis to make sure all possible stakeholders are being considered. Then go ask those stakeholders to tell you stories related to the problem that must be solved. Trust me you will have richer conversations and uncover information that the traditional user story would not. My fundamental point is that we as BA’s are software professionals that have creative analytical skills that must not be suppressed by an over reliance on any one technique. So wash your hands, clean your keyboards and get enough sleep so you can avoid Agile fever. If the BA becomes infected then the project team is certainly doomed!

The Shift to Modern Requirements

I’ve been on the road quite a bit lately, and part of my travels include delivering conference presentations about modernizing requirements.

The presentations hit home with those who are feeling the stress of increasing speed, complexity, ambiguity and change. Trends and transformations related to agile, artificial intelligence, machine learning, robotics, etc., are putting immense pressure on business analysts to build better requirements, FASTER!

This pressure is compounded by the perception that project failure is due, in large part, to inaccurate requirements gathering (2017 PMI Pulse of the Profession Survey). Is this perception a reality? Do we need to adapt our requirements approach?

Shifting to modern requirements practices does not require a major overhaul. Instead, modern requirements are the same best practices shifted slightly, with a change in mindset. Consider these three questions that highlight the differences between “old-school” and modern requirements:

Do you spend more time preparing documents or preparing techniques?

I remember the early days of my business analyst career when my requirements approach was a list of document templates. The same templates needed to be completed, reviewed and approved for every project. My job was to fill in the templates. There was little or no coaching on how to get the information needed for the templates.

Fast forward 15+ years. Now techniques drive my requirements approach. I carefully consider which technique or set of techniques will help me get stakeholders talking, thinking and collaborating. I choose techniques that will create a shared understanding that gives each stakeholder a clear picture of context, user needs, and value.


Then, I only document what is needed to remember the conversation and capture the shared understandings created by the conversation. When teams break their work into small chunks of value and working closely together, then less documentation is needed. Working with small chunks of value is why agile teams tend to document less. Agile teams have a small “work in progress” and small number team members so documenting can seem like a waste to them.

Many are concerned about documenting for audit, compliance, support, etc.—and this is valid. However, I would also argue that the requirements documentation shouldn’t be a document of what was built, rather what the user needs. There should be other mechanisms in place to document what was built.
I am not advocating for no documentation—I am simply putting out there that I believe too many teams are documenting far too much at the cost of missing out on using that time for other strategic projects and work.

Modern business analysts don’t spend time on documentation unless it provides value to the team. Instead, they apply facilitation techniques to help the team learn, experiment and create shared understanding. Modern Business Analysts strategically plan how they are going to use techniques to move the team through the evolution of the requirements from a high level to a detailed level.

This technique-driven approach makes requirements cognitively easy for the team and stakeholders. They have a deep understanding of how their work fits in the big picture. A technique driven approach can more quickly elicit and obtain more accurate requirements.

What do meetings look like?

Meetings look a lot different when a Business Analyst shifts to a technique-driven requirements approach. High impact collaboration becomes the goal of every technique they use. Meetings focus on a high-quality conversation over reviewing documentation. The high-quality conversation comes from high impact collaboration.

High impact collaboration helps BAs and stakeholders get to shared understanding faster. The quality of requirements also improves, because we get beyond stated requirements to the real needs of users.

Here is a comparison of low impact and high impact communication methods:

Low Impact Collaboration High Impact Collaboration
Reviewing text-based documents and requirements in tools Co-creating visuals, lightweight documentation
Audio only conference calls Face-to-face (video), digital whiteboard collaboration, other online collaboration tools
Sitting at a conference room table Drawing on whiteboards, working with sticky notes on walls, building prototypes, brainwriting, experiments, etc.
Email chains or instant messenger feeds or slack channels. Small group huddles (face-to-face or video conference)

How are requirements organized?

A value mindset dramatically improves the quality of the modern business analyst’s requirements. The value mindset calls BAs to organize requirements by value stream and value increment, not by system area. The value mindset puts user and organizational value ahead of the team’s needs.

BAs help their teams think like users (outside in) instead of thinking like techies and analysts (inside out). Great BAs go beyond requirements and inspire the team to organize backlogs, features, needs, issue lists and even conversations by value.

This mindset change is the key to preventing failure. Teams that focused on the user and organizational value avoid over or under engineering solutions. They prioritize what’s most important to the user, not what’s easiest for the team. This gets users what they want faster and keeps the users on board for future iterations.

When business analysts modernize their requirements, teams reduce waste. They minimize time and money spent on tasks, deliverables, features, solutions, and products that do not provide value.

Despite increasing change, complexity, and ambiguity, requirements can be done faster with better quality. When BAs use techniques that focus on value and create a culture of high impact collaboration, failure points surface faster and make addressing change less painful, with less impact on results, cost, and

schedule. In turn, modern requirements give project leaders confidence that their teams are focused on the RIGHT stuff—solutions that will deliver value to the users and the organization.