Tag: Methodologies


Best of BATimes: 99 Tips To Be A Fantastic Business Analyst

Published on August 29, 2019

1. BA yourself

This is one thing that only some professions can do. An Actuary can’t actuary himself, a developer can’t code herself, a mechanic can’t mechanic himself. We can analyze ourselves. Use your skills. Decide what a fantastic BA is; research, interview, question and then review yourself. Do some gap analysis and then formulate an action plan.

2. Be nice

No one wants to work with a jerk. No one wants to help and supply information to a jerk so engender support. Thank people, go out of your way to be personable, establish friendships and mutually positive working relationships.

3. Understand project lifecycles

Get to know all the steps in project lifecycles, not just your own and especially the intricacies and peculiarities of the adaptation used by your organization.

4. Be a mentee

There is much to be learned from Analysts further along the road than you.

5. Present well

Don’t dress like a scruff, smell nice, clean your teeth. These are surely basics but I have met people in business who have overlooked these things and they are avoided. You can’t be avoided and be successful. 

6. Prep prep prep

When you go to meet a stakeholder, especially for the first time, prepare. Understand who they are in the business and project context. Ask them for any pertinent information to be sent for your review in advance. Maximize the time with them to appear (or be) effective and efficient and they will happily give you more.

7. Be on time

Your prompt arrival in the office and at meetings will give you more poise than if you rush in late. It is the fruitage of an organized and self-correcting individual.

8. Work on your confidence

We’re not all naturally confident but by reassuring ourselves of our abilities in our BA skills or in our industry knowledge we can instill the needed confidence and trust from our business stakeholders that we can understand their world view and needs.

9. Don’t reject difficult things

They help you grow. Be the BA that accepts unusual assignments and see your career enriched and flourishing.

10. Get good at cost benefit analysis

Don’t leave this to the PM. At project inception, or for minor changes, be able to determine with appropriate certainty whether to accept or reject activity. Maintain a project which can stand-up on its own merits.

11. Be optimistic

Pointing out the bad may be necessary but if you find yourself always the nay-sayer then fix it. Problems are our business. Our optimism can make for a gentler change process.

12. Get your desk in order

Give your workspace a make-over. Keeping it clean and orderly can help you be organized and looks a lot more respectful.

13. Go to a conference or two

Hear some new stuff. Mingle with your peers. Feel proud to be part of a greater something.

14. Help others

You have a project deadline, sure, there’s always one looming but give your fellow BAs your assistance. It will broaden your knowledge and strengthen your team.

15. Be strict about your change management

Keep a record of changing requirements and details about them. It will save you the red face when, inevitably, someone will ask you later for paperwork.

16. Do your actions

If the PM has to continually chase you for your actions they will resent it.

17. Don’t be offended by the red pen

Your work will be reviewed, heavily. Welcome critique and correction. Never be upset about any proposed edits. The individual has spent time immersing themselves in your work and for that you can be grateful. It will make your work better, or at least more acceptable to your audience.

18. Volunteer to share your knowledge

Blog, post, present at lunch-and-learns, write-up how-to guides. There are always people who don’t know what you know so share.

19. Model

Use models a lot. Business people invariably find models easier to verify than paragraphs of information and it brings the potential delivery to life. Architects, Developers and Data Analysts thrive on a well-produced model.

20. Learn, learn and learn some more

If you have the means then don’t stop learning. There is so much training available in BA skills, industry knowledge, peripheral project skills, business knowledge, techniques and soft skills.

21. Offer plentiful walk-throughs

By walking-through your outputs with developers, testers and business representatives you reduce the risk of misinterpretations.

22. Finish your projects

This is especially true if you are a contractor. It’s not good practice to leave a project part-way through if you can help it.

23. Develop strategies for juggling

You will have to work on many things at once. Find what works for you to avoid loss of productivity. If you have yet to nail this there are plenty of productivity tips and hacks on the internet.

24. Clear paths for people

Be someone who anticipates down-stream problems and blockers for yourself and others and intervene.

25. Categorize people but know your exceptions

Use personality and character traits to help you understand the motivations and reactions of your team but note that exceptions exist. Tailor your interactions to fit.

26. Don’t jump to solutions

Have problem-formulating conversations to focus your mind away from solution-mode.

27. Form collaborative relationships

When you collaborate you are more likely to get early and continuous buy-in, nothing will come as a surprise to your end client and you get immediate feedback on your work. It’s worth the extra effort.

28. Find your key SME voices

The quality of Subject Matter Experts is not equal. I have seen business users hide information for a variety of reasons (most understandably) making elicitation more than the usual effort and I have had System Testers guess answers and present information as fact. Hunt for good sources of information and verify what is said.

29. Play requirements back

Saying things like: “So if I understand this right, what you needs is…” saves misunderstanding.

30. Work to uncover implicit requirements

What assumptions have you or your customers made that they haven’t vocalized. Set aside some time and thought to uncovering these.

31. Know your audience

The level of detail that you go to should reflect your audience, know this before you start your elicitation. Get it wrong and you either waste time or have to re-work.

32. Recognize that accuracy is important

Particularly in your written English. If you can’t get that right, what else might get called into question.

33. Start with context

Ask: “Why the project exists?”, “What will be the end results?”, “What benefits are sought?” Then work from there.

34. Document what you won’t build..

..and get it agreed. It doesn’t mean it can’t be changed but it will at least be recognized as a change rather than something that you missed.

35. Get creative

With care not to promise an outcome, suggest ideas and alternatives to users during elicitation. Possible options can be used as a sort of model to tease out other requirements.

36. Read widely

The IT industry is constantly changing and working practices follow hot on the heels. Our understanding of business practice, psychology, methods for collaboration and effecting change progresses. Manuals, how-to guides and handbooks to support our work are plentiful.

37. Don’t forget your non-functionals

If you don’t include these in your document template as standard, add a section for each non-functional as a reminder to consider it.

38. Don’t gild the lily

It may not be scope creep as such but it’s easy to gold-plate our requirements with unnecessary items. Admirably this is usually in response to wanting to deliver the best but these types of extras add up. Work out what your Minimum Viable Product is and then be sure to note any additions as just that.

39. Revisit your prioritizations often

Work with your group of SMEs to get your product features delivered in the right order but remember that things change so schedule re-prioritizations throughout delivery.

40. Evaluate your own skills

Choose a couple of areas for improvement, write them down and formulate some actions that will help you improve them.

41. Look for “free”/cheap benefits

By knowing what’s off-the-shelf or can be achieved with relative ease you can maximize the product and minimize the cost.

42. Ask for feedback

At suitable points during and at the end of projects get personal feedback. Asking people who will give you constructive critique is valuable. Keep it. In years to come you can see how this helped you to change and grow.

43. Find balance

Don’t neglect your personal life. Finding a good work-life balance helps you cope with the ups and downs of projects.

44. Connect with others

Associate with other Business Analysts. Everyone knows different things and that diversity is valuable. Learn, share, help and be helped.

45. Know when to shut up

You’ve raised a risk or an issue but no action has been taken, so you raise it again or differently. It’s good practice to be assertive but there comes a point when you have sufficiently noted it and taking it further causes consternation. Learn where that point is and stop before you reach it.

46. Be a mentor

You know more than you think you know. Give back to the profession by sharing that with someone following in your footsteps.

47. Work as a team

When you work with other BAs, even if you’re tasked on different items, work together. Peer review, support, offer and ask for opinion and share experience.

48. Make your research visible

If you do background reading, conduct surveys, read manuals, hold workshops then put your findings as links or appendices to your documents. Don’t make someone who may need to pick up your work at some later point have to start from scratch.

49. Expand your comfort zone

Do something a little bit uncomfortable, just a little. It will make you capable of more in the future.

(See www.batimes.com/articles/personal-growth-through-discomfort.html)

50. Be agnostic to the solution

If you begin with a pre-determined solution or have a particular software package in mind you won’t be working on behalf of your client.




51. Be flexible to software development lifecycles

Learn to work waterfall, agile, fragile, whatever your client wants. Help them build on what they have.

52. Work with positive people

When you get a choice, pick to spend your work hours with optimists. Lift your chin up and thrive with them.

53. Don’t plagiarize

It’s fine to get inspiration from other text but word them in your own way. The process of breaking something and re-working it allows you to assimilate it properly.

54. Create your own templates, improve others

If templates don’t exist within your organization start to build a repository as you work. Have one eye on how a future project may use the template. If your organization does have templates, seek ways to improve them.

55. Hone your toolkit

Rich pictures, sequence diagrams, business model canvas, running workshops.. and the other scores of tools and techniques in the BA toolkit. Practice them and then get them into your workplace. The more the merrier.

56. Encourage newbies

We were all new once. The profession is constantly refreshed with new and trainee BAs. Welcome people. Help them.

57. Don’t get stereotyped

Take on projects in areas that you haven’t done before so that you have experience and confidence in delivery in as wide a range of topics and disciplines as possible.

58. Avoid too much future-proofing

While it’s a very useful consideration some attempts at future proofing just don’t fit with the future when you get there. Unless it has wide application and has relatively no cost or impact to the project don’t overengineer it.

59. The devil is in the detail

Ask for detail and then spend time understanding complexities. If you don’t, annoying requirements will rear their ugly heads later, when you’re further down the road than is desirable.

60. Order your own tasks

It’s in our nature to do enjoyable things or things which are easy or small first and then rush others. Avoid this by monitoring deadlines and dependencies taking into account impacts from other people and their availability.

61. Decide what your goals are

Ask yourself where you want to be in 5 years and put a plan into place. It may be various certifications, it may be working on certain types of projects, with technologies or in specific locations. Work out the steps you need to get there.

62. Ask for help

No man is an island. There is no shame in asking for help whether about your career, with techniques or technical aspects.

63. Archive and catalogue

Don’t leave files, part finished documents, reference material and other artefacts as collateral damage of your work. Archive your documents, catalogue your information and generally make it easy for people to work out what are the most recent versions and what supports them.

64. Have a to-do list

Don’t risk forgetting important tasks for something as simple as keeping a list. Be organised.

65. Its ok to make mistakes

We are human and mistakes are inevitable. Know that you will make them and decide that dealing with them diligently and humbly will be appreciated and respected.

66. Estimate using metrics

If you’re asked to estimate for a piece of work, use quantitative methods as much as possible and share the information on which it is based.

67. Add a glossary

I have not seen a BA deliverable yet that hasn’t benefitted or would benefit from a glossary (either within the document or at project level). To determine what goes into it, consider your audience. You may need to add business terminology to give framework from IT readers and IT and project terminology for the business.

68. Vanilla is not the only flavor

Don’t forget about alternative flows. The abnormal activities are generally the pain points for most businesses. Overlook them at your peril.

69. Get your must-haves right

The MoSCoW rating is incredibly useful and the priority of requirements must be stated explicitly but it is only useful if you have ratified that a must-have requirement is absolutely necessary. Double check.

70. Chunk up your work and take breaks

By creating a series of much smaller tasks you maintain motivation as you complete activities and as a result have natural break points to re-energize you ready for the next task.

71. Speak up

If you see a possible method of improvement have the courage to vocalize it, respectfully and professionally.

72. Flesh out a plan but be flexible

Plan your assignments in a work-breakdown structure, so you can keep an eye on your own progress but don’t be too rigidly stuck to it that you can’t make the most of stakeholder time when they are available.

73. Do it now

If you get the choice between doing it now and doing it tomorrow; do it now. Procrastinating individual items adds up to lost time and missed deadlines.

74. Be motivated and committed

Volunteer enthusiastically, actively pursue end goals, deliver on your deadlines.

75. Find your USP

Maybe you’re a people person, good with data, can see the bigger picture, are an influencer, have specific technical expertise or domain knowledge, run killer workshops, are highly accurate….everyone has a unique selling point. Whatever it is, find it and use it.

76. Be an observer

Keep an eye on what your peers are doing. Look for cross-over and gaps between their work and yours.

77. Don’t cut corners

Guessing, not completing research fully, ignoring the quiet opposing viewpoint, not determining the full stakeholder group, failing to verify background information, removing valid approval stages are all ways to store up later problems. Don’t cut corners.

78. Run your own project

Is it possible to start a little business of your own? Doing this lets you really test your BA skills.

79. Display kindness and patience

When projects get pressurized this will make you stand out and be someone others want to have around.

80. Understand your Subject Matter Experts

Put yourself in their shoes. You’ve invited them to sit in a long meeting? Make it interesting, schedule breaks and bring biscuits.

81. Get your unfinished specs reviewed

Reduce your own risk of large rework by shipping parts of your document early and get feedback.

82. Take the initiative

Make suggestions. Improve your own team’s processes. Create bodies of knowledge. Organize socials Involve yourself.

83. Keep your requirements updated to the end

A change has been made at the eleventh hour, everyone knows about it, is there any need to take time-out to correct the documentation, especially when the pressure is on?….Yes. If you don’t, no-one will be sure of any of it in the future.

84. Take a step back

During meetings and workshops, take time to observe; interactions between people, gauge motivations. There is a lot more to be learned than comes in through the ears.

85. Control/Challenge scope

Consider scope constantly. It is the bread and butter of getting the optimal solution for the composite group of stakeholders.

86. Mock stuff up

User interfaces, documents, reports. Let your end users see and play with the final product at the design stage.

87. Minute your meetings

It doesn’t have to be War and Peace but make notes. Dictate, doodle or mind map if it’s a more effective or efficient method for you.

88. Give people a “starter for 10”

People provide what you want more quickly if they’re not starting from scratch. If you have a template, provide it. If you want data, provide the table to be populated. If you want a quote, propose a sentence.

89. Learn standards

If there is a UML or ISO way of doing something then try to use it. It’s less ambiguous.

90. Use data analysis tools

Many Business Analyst roles include research in data. You can be more self-reliant if you are capable at manipulating it.

91. Use requirement ‘numbering’ for more than a unique reference

Use prefix letter, suffix letters and sub-numbering to store information about the source (stakeholder or actor), expected delivery method (various IT systems, manual processes, teams, department or companies) and dependencies on other requirements.

Eg, CS75-S.1 (CS = Customer Services, S = SQL, .1 = 1st child requirement)

92. Don’t be vague

Make requirements specific. Eg the phrase “needs to be run regularly” should be “needs to be run twice a day, usually at 12pm and 5pm” and the phrase “other systems use it” should be “three Access databases, listed in Appendix C, link directly to the data”

93. Find your best packages

Find and get proficient with tools and application supporting BA work. Eg, for producing and tracking requirements, for producing diagrams, flows and other models, collaborating and conducting meetings, managing work, etc.

94. Change control your documents

Applying version control saves your readers’ time. Be specific about what’s changed in your version history and use function for highlighting changes.

95. Understand development basics

Gain some knowledge in the basics of development; processes, data and events, components and re-use, integration with other applications, design principles and constraints. Learning to write in a pseudo code style can help with that mentality.

96. Understand test basics

Gain some knowledge in the basics of testing; test condition design, what a tester needs from your documentation.

97. Conduct Stakeholder Analysis

Don’t leave this to your project manager, do your own. Know who your influencers are, your VIPs and any potential “troublemakers”.

98. Ask effective questions

Questions are the keys that unlock treasure troves of information. Closed questions are useful when you need to be specific and open questions are needed to allow free-flow of knowledge transfer. Learn how to make them effective and unbiased.

99. Get qualified

There are a number of qualifications tracks available in various jurisdictions. International Institute of Business Analysis, British Computer Society and International Requirements Engineering Board. For gaining knowledge in the fundamentals as well as sharpening practitioner skills it is invaluable and a résumé necessity.


The Tyranny Of “Default”: Be Careful When Choosing Analysis Techniques/Artifacts!

At its essence, a lot of what we do as business analysts involves co-creating a shared understanding. Whether that’s a shared understanding of a problematic situation, or of a set of requirements or features, a common theme is that we work to understand different perspectives and ensure that people are ‘on the same page’.

This can cause some challenges when we want to communicate complex ideas. Text is a challenging media to convey complexity, and the English language is just brimming with words that have multiple meanings. For that reason, it’s very usual to use a combination of text, models and conversations to ensure that key stakeholders are aligned.


When we create a model, we are essentially codifying some information in a way that can be later referred to. Codifying typically involves using some form of notation (whether that’s a business process modeling notation, or the symbols of an alphabet when writing text), and there will usually be particular rules on what elements of the notation mean and how they should be used.  For example, particular shapes on a process model represent particular things, particular words in a textual paragraph have a particular meaning.

Yet when we encode our analysis in this way, how often do we reflect and think “will my stakeholders understand this?”.  Will the consumers of the information both know how to read it, and, ideally like referring to it as it’s a format that works for them?  Perhaps we don’t think about this quite as often as we could…




The Tyranny Of “Default”

I have a confession to make. I love Business Process Model & Notation (BPMN).  I could quite easily ‘geek out’ and create process models to an executable level, using just about every BPMN symbol and construct that is available to me.  But, as those of you who are familiar with BPMN will attest, if I did that the resulting diagram wouldn’t be very accessible to the average stakeholder.  It would be somewhat akin to me sending an email in French to someone who only speaks English.  It might be possible to pick out some elements of the communication and work out what is going on… but it’d be very difficult to draw conclusions.

This absolutely isn’t an argument against BPMN by the way—it’s stil one ofl my preferred notations—but it highlights the importance of thinking of the artifact’s audience and choosing an appropriate level.  With BPMN, I might create a ‘view’ of a process using a cut-down palette of symbols, and model at a much higher level, so it is more intuitive. Equally, I might choose to use ‘boxes, arrows, diamonds and lines’ instead where it is appropriate to do so…

The key point here is flexibility.  It is very easy to get stuck in a rut and choose a technique because it’s the default.  You probably have a favorite approach or technique, which might mean you tend to default to a particular type of artifact. Or perhaps your organization has templates or tools that ‘nudge’ you towards a particular style.  That can be useful, it can embed consistency… but it can also lead to things being articulated in a particular way “because that’s the way we do it here, and that’s the way that we’ve always done it”.  Neither of which, on their own, are particularly compelling reasons.


Light The Fuse: Ask “Why Are We Using User Stories”

If you like a bit of controversy, next time you are working on an agile project, ask “why do we use user stories here?”.  Usually, the response will be a blank face, followed by either “because we’re agile” or “well… the tool is set up for user stories… so….that’s what we do”.

But are these really valid responses?  There’s certainly nothing in the agile manifesto that decrees user stories are mandatory.  The term ‘user story’ isn’t in the Scrum guide at all. So why default to user stories?

Of course, user stories do have merit, particularly in agile. Yet the choice to use them should be a conscious one. In fact, user stories alone are probably not enough… they will probably need to be supplemented with regular collaboration, acceptance criteria and you might even decide to document some journeys or prototypes.  It’s likely that most successful teams already do this, but it is worth highlighting.   Some of this might emerge as you discover more about the requirements… but having at least an idea of what the requirements architecture will look like up front will save pain later (e.g. “We might use prototypes, so let’s agree that one prototype will span multiple user stories… we’ll capture the links here…).

So, this article certainly isn’t criticizing user stories. However, as with any profession, we need to regularly challenge ourselves and challenge our ‘defaults’.  It is worth remembering that we have a wide toolkit at our disposal. If a plumber approached your sink with a hammer and started smashing it (rather than figuring out the right tool for the context), you’d be somewhat annoyed. An explanation of “ah, I always use a hammer” is unlikely to help.  The same is true in our profession too… and it is worth remembering how broad our toolkit is. Which provides us with many possibilities!


Business Analysis Portfolio: An Aid for Professional Development

Have you ever had a sense of business analysis déjà vu – the feeling you have used a particular business analysis technique before, but can’t quite remember what you did or how you did it? I know I have!

Business analysis is a broad and varied profession that can involve everything from narrow, well defined tasks to broad, strategic assessments. Business analysis can be performed in the context of a specific project or initiative, as part of pre- or post-project activities, or in support of ongoing operations. Over the course of a career, a Business Analyst can be exposed to numerous project delivery methods, business domains, and organizational cultures. It is this variety and continuous learning that bring many practitioners to the profession in the first place.

The BABOK contains 50 techniques, the 3rd edition of BCS’s Business Analysis Techniques 123 – it is impossible to be an expert in all business analysis techniques! While some techniques will become the mainstay of a business analyst’s arsenal, other techniques will be used infrequently to assist in specific circumstances. A final, polished piece of analysis is often achieved by carefully selecting and combining multiple techniques to build a coherent picture that encompasses different perspectives. Business context, stakeholder preference and understanding, project constraints, and a Business Analysts own personal experience can all impact technique selection.

Creating a work portfolio is a good way to keep track of the techniques you have employed in the past and the outputs you have delivered. As you move through your career, your portfolio can provide:

  • reference material to support the delivery of similar analysis products.
  • illustrative examples to use when explaining analytical approaches and deliverables to managers and junior Business Analyst colleagues.
  • a record of professional development and growth.
  • inspiration when applying for new positions or promotions.

Your portfolio can include:

  • Work Samples: Where possible, maintain copies of business analysis outputs you have produced for future reference.
  • Templates: Templates are particularly useful for those structured techniques that are performed infrequently. Generic templates can be adapted to different business contexts and domains.
  • Articles and Reference Material: Keep a record of the sources you have referenced when delivering analysis, either by keeping copies and/or maintaining a catalogue of useful books, articles, and websites.
  • Work Diary: Narrative descriptions can be used to record what you did and how you did it in enough detail for you to reference should you ever need to perform a similar task again. Use a work diary to record information about the business context, tasks perform, stakeholders consulted, and/or techniques used in the production of an analysis deliverable. Work diaries are particularly useful in circumstances where contractual restrictions, privacy and/or secrecy prevent you from holding original copies of your work. You can also use business analysis techniques in your work diary entries, such as mind maps, process models and scenarios.
  • Course Material: Include information from any courses, study groups and/or conferences you attend that might be of use in the future.




Some things to consider for your portfolio:

  • Maintain it – review your work and add to your portfolio regularly. While routine maintenance is recommended, project gateways, end of employment/contact, and/or end of year are good times to take stock of what you have achieved, what you have learnt, and what information you want to retain.
  • Organize it – you are more likely to use an organized resource then an unorganized one. How you organize your portfolio is very much dependent on you and how you work. However, aligning your portfolio with BABOK Knowledge Areas or stages of the Business Analysis Process is often a good starting point. Also consider using naming conventions and keywords to tag portfolio items to assist with searching as your portfolio grows.
  • Remember context – the amount of work required to deliver a single, pristine business analysis output is often deceiving. A myriad of techniques may be employed on route to the final, acceptable product. It is good practice to file your work with some contextual information to remind yourself of the business situation, intermediate steps, additional techniques, and issues you had on the journey to the polished artifact.
  • The good, bad and ugly while you shouldn’t dwell on the negative, remember that bad experiences are learning opportunities too. Using a work diary entry to reflect on a situation where a particular approach didn’t work can provide useful learnings for the future, as well as help put bad experiences behind you.
  • Be mindful of copyright – remember that the copyright for work you have been paid to produce for another entity is almost certainly held by a third party. Take care to respect all copyright. When in doubt, de-identify information and/or use work diary entries in place of original copies. In cases where you do own the copyright, you may still want to take care when sharing material as it is your IP!
  • Be creative – while you will most likely draw on your professional roles for the most of your portfolio examples, there are other, creative ways to build your portfolio. Many aspects of life can benefit from a bit of business analysis rigour – getting your home budget under control, selecting the best suburb to move to, or assisting a community organization to suggest a few. It may sound flippant but using techniques in general life can be a good way to try new techniques, apply techniques in a different context, and build examples to draw on in the future, particularly when you are just starting your business analysis journey. (You never know, it may also help you achieve a better outcome for you, your family, and/or community group!)
  • Use it – a portfolio is only valuable if it is used… so remember to use it!
1.  Business Analysis Book of Knowledge v3, Institute of Business Analysis, 2015.
2. Cadle J, Paul D, Hunsley J, Reed A, Beckham D, Tuner P, Business Analysis Techniques: 123 essential tools for success (Third edition), BCS, 2021.

Introduction to the Jack Method: Trees and Stories

This is the farmer sowing his corn,
That …

That …
That lay in the house that Jack built.
An English nursery rhyme

A jack is a connector that installs on the surface of a bulkhead or enclosure.


The Jack method comprises techniques and concepts for comprehensive root cause analysis, scope modelling and requirements management. It is underpinned by the following principles:

  • ‘Simplicity – the art of maximizing the amount of work not done – is essential’ (Agile)
  • ‘Assume variability; preserve options’ (SAFe)
  • ‘Divergent and convergent thinking’ (Design Thinking).

The core techniques –Jack Trees and Jack Stories – are presented in this article.

The analysis is based on the Case study ‘The Good Kitchen’ where Danish government was concerned that Denmark’s seniors in assisted living facilities or residential care units had poor nutrition (https://thisisdesignthinking.net/2016/05/the-good-kitchen/).

Jack Trees


Jack Trees are the key element of the Jack method. It allows to perform analysis in ambiguous environments with limited access to subject matter experts. Promoting identification of unexpressed assertions, it creates a traceable structure of requirements ranging from solution-agnostic business needs through to detailed specifications. Jack Trees are a perfect tool to make conversations with stakeholders productive, and to enable confirmation what’s in scope and what’s out.


A Jack Tree is a hierarchical list of statements that follow a specific format:

  • Each statement delivers an unambiguous (and therefore short) message
  • A statement contains an action and an object
  • Statements in the hierarchy relate to each other as ‘one to many’
  • The statement of the higher level is called an ‘objective’, of the lower – an ‘option’
  • Statements are formulated in a way that options address the objective
  • The highest statement in the hierarchy usually corresponds to a Business Need, the lowest statements are usually acceptance criteria or specification items
  • Each statement can serve as an objective or an option depending on the depth of analysis.

To shorten the definition, a Jack Tree is a hierarchical list of action statements where each objective has at least two solutions.

To create statements, the Semantic Analysis and Minimum Meaningful Message techniques can be used (it will be described in a separate article).

Mathematically, a Jack Tree is a Directed rooted N-ary tree. Hence, specific properties such as terminology, relationship cardinality, isomorphism, calculus, etc. are inherited and can be applied to the Jack Tree.

Example of a Jack Tree branch may look like:

  • Improve quality of food
    • Increase meal nutrition
      • Add supplements
      • Increase meal size.


The Jack Tree is all about alternatives. Each statement is to be challenged for an existence of a concurrent option. Alternatives are being identified and grouped under objectives, and objectives are reviewed to be matched, renamed or split, until the desired outcomes are achieved.

The ideal Jack Tree represents a logical flow of statements explaining how different levels of objectives can be addressed by a number of options. Every option is unique even if it looks the same – where there are identical or similar option statements, they still relate to different objectives providing a different context. It is also important to mention that it is never the only variant possible for the Jack Tree, as the analysis view can be changed based on new findings or analysis focus.

The short algorithm of a Jack Tree creation is as follows:

  • Create a semantically refined statement (action + object)
  • (↓ ‘look down’) Treating it as an objective, devise at least two solution options to address it
    • Where nothing comes to mind, try using the ‘Do nothing’ option
  • (↑ ‘look up’) Treating it as an option, devise an objective the option can be addressed by it
  • Refine wording where needed – it promotes solution-agnostic formulation
  • Continue moving up or down the Jack Tree, adding branches, objectives and options till the desired analysis granularity is reached
  • Consider the Jack Tree completed when requirements are detailed enough.

Once the Jack Tree is created, all options need to be reconfirmed with appropriate stakeholders. Talking through the options will evoke highly valuable insights on what the current and future states are, along with confirming the scope.

It is imperative to note that knowing what’s in scope is as important as knowing what’s out of scope. The Jack Tree technique gives a perfect indication of that.

Additionally, it is practical to use a ‘Do nothing’ option as an alternative where applicable. However, ‘Do nothing’ is an option that also requires an action, and should be equipped with associated acceptance criteria or specification, e.g. ‘Continue spending $1,234 monthly on support’. This allows for more careful scope considerations.


Building a Jack Tree can be started from a requirement of any level, looking up (confirming or generating possible objectives) and down (decomposing solution options to the desired level of granularity). It doesn’t matter how the requirement is obtained – through elicitation or formulation. In our case the possible initial requirement can be:

  • Increase meal nutrition.

It is quite easy to identify immediate solutions for the requirement – this is how our brain usually works. So let’s go with:

  • Increase meal nutrition
    • Add supplements
    • Increase meal size
    • Increase calories.

All second-level options satisfy the requirement by answering the question ‘What do I need to do in order to <objective>?’, e.g. ‘In order to ‘Increase meal nutrition’, I need to ‘Add supplements’.

Now let’s look up and check the correctness of the objective for every specified option: ‘If I <option>, would it <objective>?’, e.g. ‘If I ‘Increase meal size’, would it ‘Increase meal nutrition’? We can see that the objective and the options correlate perfectly.

Note that any of the options at this level can be broken down further (e.g. ‘Add supplements’ can at least be broken down into ‘Add vitamins’ and ‘Add minerals’).

Now, let’s test the ‘Increase meal nutrition’ statement as an option that has an objective. What purpose can this solution serve? What alternative would this solution have? Do all devised solutions correspond to the objective?

Please note that the most obvious answer ‘Improve health’ brings too broad spectre of solution alternatives:

  • Improve health
    • Increase meal nutrition
    • Visit a health resort
    • Do physical training.

It’s a signal that additional iterations are required to clarify and narrow down the Jack Tree branch.

After multiple iterations of the algorithm, a Jack Tree similar to the one below can be created:

  • Improve quality of life for seniors
    • Improve dining experience
      • Satisfy dining habits
        • Have dinner alone
        • Have dinner in a company
      • Improve quality of food
        • Increase meal nutrition
          • Add supplements
          • Increase meal size
          • Increase calories
        • Change food type
        • Change quality of ingredients
      • Make meal appealing
        • Improve meal taste
          • Change cooking method
            • Sear food
            • Steam food
          • Use spices
        • Improve meal appearance
          • Use separate boxes
          • Use pre-arranged meals
        • Improve range of dishes
          • Construct custom meals
          • Collect pre-orders
          • Introduce menu
          • Have multiple options cooked
        • Change food type
          • Change food consistency
          • Satisfy diet restrictions
            • Vegetarian
            • Gluten-free
            • Fasting
          • Improve food preparation process

Note that the analysis organically revealed true business needs confirmed by the actual Use Case, e.g. attention to cultural, reputational and behavioral aspects, and changing the cooking practices.

Unlike the costly and lengthy group effort during ‘The Good Kitchen’ initiative, the above analysis could be done by just one analyst within a day or two. This is where the real power of the Jack method resides.


Pros & cons:

A Jack Tree has commonalities with different techniques and concepts, but it has a number of advantages that are unique:

  • Identifies true business needs
  • Promotes solution-agnostic view
  • Establishes full traceability
  • Allows to operate with insufficient data
  • Provides a holistic Product view
  • Visualizes the scope not done
  • Clearly communicates the solution context
  • Promotes clarification of stated requirements
  • Allows for staged prioritization
  • Allows for effort estimation on different paths
  • Gives awareness of the entire backlog
  • Identifies gaps in analysis
  • Allows for algorithmic processing.

Once understood and adopted, the Jack Tree technique doesn’t provide any immediate downsides. Every challenge that occurs during the analysis, essentially improves the holistic understanding of the product, which is always beneficial.

Jack Stories


A Jack Tree provides perfect input for traditional User Stories, and also promotes a specific story format – Jack Story, the technique that is part of the Jack method.


The traditional format of the User Story is:

As a <Role>
I want to <Option>
So that I can <Objective>

As a Business Owner,
I want to Add supplements
So that I can Increase meal nutrition

When the role is insignificant or vague (which is often true for system-related requirements), an Enabler story format can be used:

IN order to <Objective>
WE need <Option>.

IN order to Increase meal nutrition
WE need to Add supplements.

A Jack Tree can immediately generate numerous conventional User Stories/Enablers, joining together Options and Objectives. Several stories may have the same ‘So that I can’ part, emphasizing different options for implementation that satisfy the same objective. This often happens ‘in the middle’ of the branches where options are being actively explored but haven’t got to the specification level yet.

However, the brevity of Jack Tree formulation may adversely affect the level of context provided. To alleviate this, a Jack Story can be used.

A Jack Story is a format of the requirement that traces an option to all its objectives up to a desired level. To build a Jack Story, a minimal Jack Tree branch needs to be created. Once the Jack Tree is available, the traditional formats of stories can be converted:

As a Business Owner,
I want to Add Supplements
So that I can Increase meal nutrition
So that I can Improve quality of food
So that I can Improve dining experience
So that I can Improve quality of life for seniors.

The same exercise can be done for the Enabler format.

A Jack Story gives a lot of additional context and indicates the way the logical considerations have been put into analysis.

Generally, the notion that a User Story is a Jack Story indicates that:

  • There exists a hierarchical list of options (Jack Tree)
  • Each statement in the story has been considered for an alternative
  • The story purpose is understood and is traceable back to the highest known element in the hierarchy (up to a Business Need).

It is not hard to notice that the Jack story format application for traditional stories is clunky and doesn’t sound natural, especially for longer constructions, or when the user focus is changed.

A new format of the story-like requirements format is therefore proposed. Analyzing the semantic structure of a solution option in the Jack Tree, we can see that it is represented by an Object and an Action. Breaking down the first option, and leaving objectives as is, the format of the Jack Story is:

This is the <Object> I want to <action on> (Option)
To <Objective 1>
To <Objective 2>
To <Business need>

This is the supplements I want to Add
To Increase meal nutrition
To Improve quality of food
To Improve dining experience
To Improve quality of life for seniors.

The Jack Story is the most natural and accurate representation of the Jack Tree requirements.

Empirically, when working on user stories organized in Epics, on average just 2-4 levels of requirements hierarchy are sufficient to provide enough context in the Jack Story. This makes Jack Stories more readable, concise and referable.

Pros & cons:

Jack Stories are a representation of the Jack Tree, and inherently obtain many advantages:

  • Fully compliant with INVEST criteria:
    • (I)ndependent – each option in the Jack Tree is an alternative that can be developed independently
    • (N)egotiatable – Jack Tree provides a variety of alternatives that can be selected on their own or broken down further until satisfiable
    • (V)aluable – each option in the Jack Tree has a reason to exist, therefore the value is well defined
    • (E)stimateable – looking up and down the Jack Tree gives a perfect idea of what an option comprises, thus making it easy to estimate
    • (S)mall – Jack Story formulation is dependent on the scale of view, and can be as small as needed for the development iteration
    • (T)estable – because Jack Stories are intrinsically short, Acceptance Criteria are an integral part of it.
  • Solution-agnostic at the high level, very descriptive at the detailed level
  • Short and concise, it fits easily on a story card and is easy to communicate
  • Naturally traceable
  • Unique and helps to keep the scope from creeping
  • Translates requirements easily from Waterfall to Agile
  • Promotes categorisation and critical thinking.

Along with the pros, there are some cons:

  • Requires creation of the Jack Tree
  • May need additional description and/or Acceptance Criteria
  • Not widely accepted hence requires explanation.

Jack Method


Jack Stories/Trees are powerful techniques for solution options analysis, especially when access to stakeholders is limited. To excel the method additional original concepts and techniques can be useful:

  • Semantic analysis
  • Minimum Meaningful Message
  • Traffic Lights (Semaphore).

The method makes scope better defined, requirements more structured, and prioritisation easier, contributing to the value of Business Analysis.


Best of BATimes: Business Analyst Jobseeking tips – Acing The Interview

Published on: January 7, 2021

The business and economic environment is incredibly tough right now, and I know from conversations with some of my connections that it’s a tricky time to be a BA jobseeker.


Competition is rife and it can be a challenge to know how to really shine in a job interview.

I recently facilitated a webinar panel session with Michelle Shakesheff and Saffron House (two senior BA managers) on this very topic.  This article summarizes some key takeaways from that session, with a few of my own thoughts added in for good measure.  It’s important to keep in mind that I’m based in the UK, so I’ll be reflecting on the expectations for job interviews here—I am sure expectations differ across the world so be sure to check out other articles and resources too.

Preparation Is Everything

When it comes to a job interview, preparation is everything.  There are many aspects that need to be considered, including the three ‘Rs’: Research, Role & Rehearsal.

Firstly, if you’re serious about working for a particular organization, then it’s crucial to research it.  This doesn’t have to be time-consuming, can be entirely ‘desk-based’ and is an opportunity to use a range of strategic business analysis tools.  You’ll want to check out the organization’s website, if it’s a large organization it’ll probably have an annual report.  What is its stated mission and strategic objectives? What are its stated values? Techniques such as VMOST can be useful for helping us to understand where a company is heading.  Approaches such as STEEPLE are excellent for brainstorming external factors that might affect the organization.  You might want to assess what you consider to be the biggest external opportunities and threats to the organization.  Utilizing these (and other) techniques alongside general research will provide a picture of the types of project that a company is likely to be undertaking.  You’ll pick up the language of the industry and organization, you’ll be well-placed to give specific answers to any strategic questions that the interviewer asks even if these don’t crop up, you’ll be well-placed to ask a relevant question about the organization’s strategy.  You’ll also get a sense of whether this is a company that you’d fit into and actually want to work for!

Secondly, there’s the role. Read every detail of the job description, person specification and whatever artefacts you can get your hands on.  Think back to your experience and be prepared to give an example for every skill or competency that is listed.   One senior manager I used to work with always advocated creating a table to systematically work through a job description, breaking it down into its component parts and adding an example against each.  If you do this, you’ll have the right example on the tip-of-your-tongue and won’t hesitate if a question crops up.  Here’s an example:

Requirement on job spec

My example

My contribution

The outcome

Process modeling & analysis

XYZ Project: analyzed 25 processes, proposed improvements. Used BPMN.

Led process discovery, as-is and to-be modeling. Resolved conflict through workshopping.

All processes were implemented. Stakeholders loved the new processes as they’d been involved throughout.

Resolving conflict

ABC Project: Removal of permanent desks.

Ran a prototyping session so ‘hot desking’ workers could see the benefits.

Stakeholders who were reluctant became advocates.

Analyzing business rules




Finally, there’s the rehearsal.  I remember hearing polar explorer Allan Chambers speak over a decade ago.  He gave the sage advice ‘never take your body somewhere your mind hasn’t been’.  This applies for interviews too: take your mind to the interview room (or virtual interview room).  Imagine the types of questions you might encounter, formulate your response, and say them out loud.  What is the first thing you’ll say to the interviewer?  You’ll get different questions on the day, of course, but you’ll feel more confident and prepared and your answers will likely be slicker and well-informed.   This brings us neatly to our next topic, questions.




There Are No “Top Ten” Interview Question Lists

Although this might sound disappointing, there really aren’t any “standard” BA interview questions.  There might be patterns that crop up, but the questions are going to vary depending on the specific requirements for the role.  It’s also highly likely that there won’t be a “right answer” to any particular question—put yourself in the shoes of the interviewer and think what are they trying to understand from this question?  And don’t be afraid to ask for clarification.  It is genuinely hard to create unambiguous interview questions, and speaking personally, whenever I’ve been involved with interviewing candidates I take requests for clarification as an extremely positive thing. After all, BAs ought to be clarity-seekers!

It’s also important to answer the question that’s asked, not the one that you might have hoped the interviewer has asked.  I’ve fallen into this trap myself in the past, and I can tell you it doesn’t end well… However, if you’ve considered the different areas of the job specification and have examples for each area you’ll be well prepared to pivot and adapt on-the-fly.

A word of warning here. One trait that seems to be common amongst most BAs I’ve ever met (myself included) is the tendency to say “we”.  As BAs we work with others, and a success is a team success.  This is fine in most circumstances, but job interviews are a place to say I as well as we.   By all means discuss what the team achieved, but remember the job interviewer is going to want to know what you contributing.  Hearing “We created and prioritized a backlog” is interesting.  Hearing “I worked with the PO and coached them on the user story format. We experimented with different formats, but settled on user stories with some attached scenarios and acceptance criteria, which I wrote on behalf of the PO…” is more useful.  Precision is great.

Talking of precision, frameworks can act as a common language.  Being familiar with industry frameworks such as IIBA’s Business Analysis Body of Knowledge guide (or whichever is relevant for your context) can help.  Using industry standard terminology such as requirements elicitation, strategy analysis, requirements lifecycle management and many, many more besides will help ensure that you and the interviewer are on the same page.  Of course, it’s likely that the organization will have its own internal framework.  If you’ve been able to learn about that in advance through your research, then use those terms too.

Remember: An Interview Is Two-Way

It might seem like an interview is purely for the employer, but this is far from the truth.  It’s also you’re opportunity to assess whether the organization is a good fit for you.  Do the interviewers treat you respectfully?  Do they keep failing to turn up for the interview at the last minute without explaining why and then re-arranging?  Keep in mind that an employer that treats candidates without due respect may well treat employees similarly.

On the flip side, you may well find you get on fantastically with the interviewers, and all of your instincts are that this is the job for you.  Be sure to take the opportunity to ask the interviewer questions too.  You might ask them about the size of the team, the challenges they are facing—this might be a chance to showcase the research that you’ve done and ask them a specific question about the strategic direction of the organization and how it impacts the BA team.  Choose the right questions for the context, and use it to learn about the organization and the role.


Job interviews are nerve-wracking, but those nerves push us to prepare and perform well.  Remembering the three Rs: Research, Role & Rehearsal, thinking about the questions that might be asked and remembering an interview is a two-way process can help.