Skip to main content

Tag: Tools

BATimes_Mar15_2023

Your Next Process Model’s Degree of Abstraction

Written by Edmund Metera on . Posted in Articles.

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)
BATimes_Mar2_2023

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on . Posted in Articles.

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

 Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

  • Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

  • Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.

 

Advertisement

 

  • More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

  • Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

  • Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.

BATimes_OCT27_2022

Business Analysis Portfolio: An Aid for Professional Development

Written by Anna Rajander on . Posted in Articles.

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.

 

Advertisement

 

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!
References:
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.
BATimes_OCT20_2022

Introduction to the Jack Method: Trees and Stories

Written by Igor Chebanenko on . Posted in Articles.

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

Intro:

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.

Theory:

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.

Algorithm:

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.

Application:

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.

Advertisement

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

Intro:

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.

Theory:

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.

BATimes_June22_2022

Requirements Gathering: Pants or not?

Written by Mike Boris on . Posted in Articles.

It’s been a long time since I’ve had to wear real “business casual” pants to work. Not since the Before Times has a client seen me from the waist down. Well not anymore! For the first time since February of 2020 I will sit down with a client…in person…in a room…with pants on. I can’t tell you how happy that makes me.

We BAs are social creatures. Being locked-up in my house for the better part of 2 years was not…shall we say…optimal. Don’t get me wrong, It was great spending every minute… of every hour… of every day with my lovely wife of 32 years. Really…it was…great. It’s just that I struggled to do my job well… heck, I struggled to get out of bed sometimes.

I have spent 30 years splashing around in the wading pool of process design and improvement…and almost every day was spent interacting with live human beings. A June 1st article in the BATimes by Lee Templeton, listed “10 Soft Skills You’ll Need To Be A Successful Business Analyst” (check it out, it’s a good read). As she points out, these soft skills are people related skills…you know…for working with people. I have these skills! I’m really good with these skills! But now that the world has seen that working from home actually…er… works from home… there’s a perception that getting together in a brick and mortal room is no longer necessary (as if donuts and coffee weren’t necessary). Unfortunately most, if not all, of the skills on the list… the skills I have… suffer in both application and effectiveness during a virtual meeting.

We all know that rapport building is the poster-child for BA skills. It’s number 1 on Ms. Templeton’s list for a reason. We can’t do our job without it. Clients need to trust us. We’re going to get them to air their dirty laundry… to tell us the bad and the ugly as well as the good. They say “you can’t read the room on a Zoom”. A more truthful statement has ne’er been uttered. I need to pick up on the vibe in the room so I can adjust my strategy, delivery, and approach. Where are people sitting? Is their body language open or defensive? Who’s giving furtive glances to whom? Well let’s see…people are sitting at their kitchen tables…their body language is, well …slouchy… and they can’t glance at anyone. Of course, I can see that much only if they have their cameras on! A quick show of hands…who’s had their initial meeting with a group of SMEs where everyone had their video turned off? I swear I lose a little piece of my BA soul every time a window goes dark. Oh, I can build that rapport, and those relationships… eventually… but what I could do in 30 minutes in person can take hours online. C’mon SMEs! I don’t have all day!

Back to the list…Enthusiasm. Great…I’m enthusiastic. This should be an easy one. But just how enthusiastic can I be when I’m a head in a box? I’m talking with my hands like an Italian grandmother…showing how this flows into that, where this step loops back to here…and no one can see it! OK…Creativity… creativity… maybe I should throw up a whacky virtual background… break some ice… get a chuckle from the guy sitting out on his deck. What do I have that wouldn’t A) offend someone, B) make me come across as goofy and unprofessional, (as opposed to goofy but professional?), or C) make my head disappear? Ugh. Boring corporate logo it is.

So what’s a BA to do? Well, we need to Adapt (another soft skill from Ms. Templeton’s list). We need to find new tools and techniques that not only allow us to do what we did in the Before Times, but to do it better. We need to embrace the new reality, jump on the bandwagon, go with the flow, and do some other catchy phrase that hopefully involves the word “paradigm”.

Remote learning for school was the necessity that drove the invention of new types of learning software. The glazed-eye inducing PowerPoint deck was joined by game-based and interactive Q&A platforms, concept visualization tools, old-people-friendly software for creating short videos and animation, and my favorite…virtual whiteboards. I have fond memories of the smell of a new dry-erase marker in a room with whiteboard walls… of gliding around the room scribbling this over here, laying down an arrow to that over there, drawing a cow in the corner while everyone’s on a bio-break…ah, the good ol’ days. But we must Adapt, right?

Advertisement

My first go at Adaptability was to find an online whiteboard. Boy howdy! There’s a lot of ‘em. Here’s as far as I got before succumbing to virtual overload. (deep breath, here we go)… Microsoft Whiteboard… Miro… Explain Everything… TutorialsPoint… Educreations… Limnu… Mural… Groupboard… Ziteboard… ConceptBoard… LiveBoard… StormBoard… ThisBoard.. ThatBoard, and TheOtherBoard… and my favorite “we’ve run out of whiteboard names” board: FigJam. It was interesting to see the differences in functionality…and by extension, the requirements the BAs wrote. Some were straight up blank boards (i.e. lazy BAs), some were big on templates, some had magic Post-It notes, some allowed you to embed files, some had voting and cute little avatars, and some tried to do everything…and failed spectacularly. I even bought a graphics pad and pen to see if my horrible handwriting was just as horrible in the virtual world. It was worse.

OK, so I spent so much time on the virtual whiteboard tool investigation that I stopped there… but my point is that there are options out there for adding virtual tools to our BA toolbox. Software, however, is not a soft skill. It’s only part of the picture. We need to consider what new people skills we might need. One example is Virtual Contributor Management (I just made that up).  We’ve all had to deal with the “Dominant Contributor”. You know, the guy who takes over the conversation, is first to jump in with the answer or a comment, and routinely interrupts polite people. He’s hard enough to manage in a room, but in a virtual meeting, he can shut down the highly knowledgeable, but introverted, SME with much greater efficiency and speed (not a process improvement, by the way). We need to learn, and get comfortable with, how best to “mute” a Dominant Contributor (without using the actual “mute” button…although…) and invite others to join in. We also have to sort out the “You go; No, you go; No, you go…” politeness pit of doom. Our audience is now scattered to the four winds, and we have to be able to wrangle them into a cohesive, responsive source of information. What? Are you looking at me for the answer… Good luck because I don’t know. That’s a soft skill I’m working on.

But I don’t need know how to do that just yet, because next week I’ll dust off my neglected khakis, pack up my Big Bag o’ Real World Soft Skills and go meet with actual warm bodies in a real room with a real whiteboard! Maybe I’ll even bring donuts.

 

Note to self: Socks…don’t forget socks.