Skip to main content

Tag: Agile

BATimes_NOV9_2022

Best of BATimes: 4 Business Analyst Interview Questions And Answers To Kickstart Your Career

Written by Jimmy Rodela on . Posted in Articles.

Published on November 7, 2019

If you’re just starting your career as a Business Analyst (BA),

 

knowing the usual types of interview questions can help you prepare to impress your potential employers.

After all, knowing the possible interview questions will help you prepare the right answers that will make you stand out from other candidates who are vying for the same position.

Although the requirements for Business Analyst positions vary depending on the company, there are a set of common questions that you’re most likely to hear in every interview.

These questions could range from a simple “Why a career in Business Analysis?” to more in-depth queries, like the kind of tools you use, so the more familiar you are with these questions, the better equipped you’ll be to ace your interviews.

To aid you on how to do just that, here are four Business Analyst interview questions and possible answers to help you prepare to leave a positive impression on your prospective companies.

Question 1. What Is The Role Of A Business Analyst In A Company?

As a business analyst, you play a crucial role in guiding businesses to improve their products, services, software, and processes through data analysis.

Plus, you can bridge the gap between IT and your employers to help boost efficiency and translate data into useful and actionable insights.

As such, you’ll need to emphasize the specific roles of business analysts. If you have experience in the field, discuss some of your previous functions with your interviewers.

BATimes Nov07 01

Here are some of the things you can consider to help you discuss the roles of a BA.

  • Business analysts can take on specific roles within a company project such as System Analyst, Application Designer, Business Planner, Technical Architect, Data Analyst, etc.

If you’ve played these specific roles in the past, expound on what you did and the solutions you came up with.

  • The job of a BA will vary based on the requirements of your potential employer – some BA roles may be limited to IT projects, with a few extending to marketing, accounting, finance, and more.
  • Your primary role as a BA is to help determine the needs of your company, uncover the problems – including using predictive technology to predict future issues (to some extent) – and come up with business solutions.
  • Aside from technical skills, your role as a BA will require you to have a good grasp on engineering concepts, possess leadership qualities, and excellent communication skills.

Question 2. What Are The Crucial Tools For Business Analysis?

There is a wide array of tools and software that business analysts use to perform several functions required of the role.

With that said, interviewers will ask you what the crucial tools are for business analysis so they’ll know which ones you’re proficient in and what you can bring to their company.

If you are proficient with tools like MS Office, Structured Query Language (SQL), Blueprint, programming languages such as Python and R, Tableau, and more, bring them up during the interview.

Most interviewers will also ask you outrightly about the tools and the training you are certified in, but instead of going through the whole list, bring to focus a few of your most recent ones.

For instance, if you have undergone a CBAP certification training course, then discuss how it has enhanced your skills and how you can apply it to your prospective company.

BATimes Nov07 02

Doing so helps give your potential employers an idea about your skills and proficiency, and whether or not you already have what they need or if they need to train you for specific tools.

 

Advertisement

 

Question 3. How Do You Handle Difficult Stakeholders?

Remember that being a Business Analyst means coming up with solutions, but you’ll also need to prepare for the possibility when your proposed solutions are met with resistance.

Many factors can contribute to this, but among the rest, human factors like – difficult stakeholders – might be one of the most challenging to handle.

Your potential employers will want to know how you can manage this type of situation since it is bound to happen in every company.

You won’t need to provide an entire outline of your answers during your actual interview, but keep these few points in mind when formulating your possible responses.

  • Spot your “difficult” stakeholders from the group, listen to what they have to say, and exercise a significant amount of patience.

If you cut them off or be impolite towards them, it will only lead to misunderstandings, and that will not help you resolve any of your issues.

  • Some stakeholders are difficult because they are not comfortable with some of the things in your project. So take the time to dig deeper into their issues by listening to what they say and answering any questions they might have.
  • As much as possible, meet and discuss with your difficult stakeholders personally as a way of showing them that you are committed to working towards the same goal with them.
  • Continuously engaging your difficult stakeholders helps them understand that their contribution is valuable to your project. Their resistance could also stem from valid points of view, so it’s crucial that you don’t just dismiss their opinions.

Keep in mind that there are no perfect answers, but being prepared for possible questions like this will always help you have concrete responses.

Question 4.  Do You Have Any Questions For Me?

Asking tons of questions comes with the job of being a Business Analyst, and one of the best places to demonstrate your ability to ask relevant and insightful questions is during your interview.

This part of the interview that you can turn into a conversation by asking questions about the company, its processes, and more.

Aside from demonstrating your abilities, asking relevant questions also shows your potential employers your interest in their company, which can only help increase your chances of getting the job.

BATimes Nov07 03

Here are a few questions that you can ask your interviewers.

  • “How does your company handle systems analysis, and do you have a dedicated systems analyst?”

There are companies with job postings for BAs when what they really want is a Systems Analyst/BA, so it’s best to clarify this ahead if this is not the type of role you would like to fulfill.

  • “Which project phases are your BAs involved with?”

If your interviewer says that business analysts are only involved in requirements, then the company might be looking for a Requirement Analyst specialist.

This might not suit you if you want to perform a deeper and wider BA role, so you should get this out of the way during the interview.

  • “Does your company have a central BA team, or does each function have its own BA team?”

Asking this question will help you determine whether or not there is a central team that will allow the pooling of knowledge.

Bottomline

There might not be perfect answers to your business analyst interview questions, but being prepared by learning the possible responses will help equip you for the big day.

Remember that being a business analyst means solving problems, and your interview Q&A is the first obstacle you need to overcome in a long list of challenges coming your way in a BA career.

Also Read: Business Analyst Manager Interview Questions

Did you learn something from this post? Please share this with your network if you agree. Cheers!

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_OCT12_2022

How Does Agile Analysis Certification (IIBA(r)-AAC) Fit?

Written by Tom Tomasovic on . Posted in Articles.

Agile is here to stay!

 

Being a capable business analyst in an agile environment is no longer a specialization. Every competent BA must be comfortable working in an agile environment, and that should be reflected in the certifications offered by the IIBA.

 

Version 3 of the Guide to the Business Analysis Body of Knowledge (BABOK) was released in 2015. This version identified agile analysis as one of five sample perspectives that “provide focus to tasks and techniques specific to the context of the initiative”. Other perspectives included business intelligence, information technology, business architecture, and business process management. The expressed intent was that these perspectives represented common views of business analysis, and that they should be applied as appropriate in any project context to provide ways to approach business analysis work.

 

At the time, there were ongoing “debates” in the community regarding the need for or value derived from including business analysts on agile teams. Indeed, the identification of roles in the Scrum Guide: scrum master, product owner, developer, motivated many (misguided?) teams to specifically reject the notion of business analysts as necessary or desirable members of a Scrum team. This premise became common throughout the industry.

 

Advertisement

 

Parenthetically, I have always found it interesting that no one seemed to question the inclusion of testers as a specialized role on Scrum teams.

 

Why overlook business analysts? The question could generate an article unto itself.

 

As agile methods became more widely accepted, it was clear the business analysis domain needed to address this oversight. The IIBA partnered with the Agile Alliance to create and release version 2 of the Agile Extension to the BABOK Guide in 2017. The Extension was intended to demonstrate the need for business analysis in an agile context and to clarify the application of solid business analysis, independent of project context or development paradigm. The Guide “demonstrates how an Agile mindset can be applied to all domains and how any BABOK® Guide task can be performed in an agile context”[i].

 

In 2018, the IIBA introduced the Agile Analysis Certification (IIBA®-AAC). This was the first of their “specialty” certifications, expanding on the core certifications: Entry Certificate in Business AnalysisTM (ECBATM), Certification of Competency in Business AnalysisTM (CCBA®), Certified Business Analysis Professional (CBAP®). The certification was designed to be methodology-agnostic, focusing on the business analysis principles necessary to support iterative, adaptive development, independent of the domain. Some new techniques were introduced, but by and large, the focus was on how good business analysis practices described in the BABOK® should be applied in an agile context.

 

No one should argue that doing business analysis in an agile, change-driven context is the same as traditional, plan-driven analysis. The differences, however, focus largely on the timing and the level of detail in the application of standard BA practices. The same practices generally apply regardless of the team’s development approach.

 

Fast forward several years, and the agile paradigm is dominant in the software industry. Many organizations are extending, transitioning, or having transitioned to agile frameworks and methodologies. At the same time, those frameworks, methodologies, and teams have recognized that business analysis is not antithetical to agility. Indeed, business analysts or those project team members having strong business analysis capabilities are now seen as vital to successful initiatives.

 

Where does that leave the AAC? As of August 2022, the IIBA Certification Registry lists 1,474 registered holders of the IIBA®-AAC. This may not represent the entire total, as holders can choose to exclude their names from the directory. Compared with the other core and specialty certifications the numbers tell an interesting story:

  • ECBATM – 7,359
  • CCBA® – 2,743
  • CBAP® – 16,331
  • IIBA®-CBDA (Business Data Analytics Certification) – 338
  • IIBA®-CCA (Cybersecurity Analysis Certification) – 253
  • IIBA®-CPOA (Product Ownership Analysis Certification) – 634

 

Clearly, the core certifications are more popular than the specialty certifications. This is particularly true of CBAP®, which has been around for a longer time, requires verifiable work experience, and has more recognition in the marketplace. There is more interest in AAC than any of the other specializations, but that may be a result of the length of time AAC has been available in comparison to the other specialty certs.

 

What I find most interesting, however, is the integration of agile principles with the other specialty certifications. The IIBA emphasizes that the specialty certifications, particularly CBDA and CPOA, which is really an Agile certification, include the application of agile techniques along with an expectation of the application of techniques and practices from the BABOK®.

 

People preparing for certifications have a duty to understand more than just “what’s in the book”. To be an effective BA, the practitioner needs to be able to apply techniques and practices from any perspective that will support the initiative. In providing training for aspiring BAs and certification candidates, I often refer to information not only from the BABOK®, but also from the Agile Extension and a variety of other agile frameworks and methodologies.

 

Going forward, I can easily see the AAC being rolled into the core certifications, particularly at the ECBATM level. While that would eliminate one outlet for my services (AAC certification courses), I think it would ultimately serve the domain and result in better BAs.

[i] IIBA and Agile Alliance Release Version 2 of The Agile Extension to the BABOK Guide (https://www.agilealliance.org/the-alliance/news-press/iiba-and-agile-alliance-release-version-2-of-the-agile-extension-to-the-babok-guide/#:~:text=The%20Agile%20Extension%20to%20the%20BABOK%C2%AE%20Guide%20will,be%20available%20for%20enterprise%20licensing%20in%20September%202017)

 

BATimes_Sep28_2022

Improve Prioritization Using a Combination of Techniques

Written by Steve Jones on . Posted in Articles.

Software development projects have a long history of unsuccessful delivery for myriad reasons. A lack of success is often determined by what didn’t make it into the final product release; like a core functionality, while some enhancement items did make it in. This begs the question, “Why weren’t all of the core capabilities the focus until they were complete?”

Rarely does everything in the requirements get implemented, so knowing the core capabilities is necessary to keep from getting derailed by enhancement requests. When a project includes multiple stakeholders, it isn’t uncommon they end up fighting for the wrong thing as it relates to the project, “their stories.” What gets lost in all the fighting over each stakeholder’s “priorities” is the real goal – achieving the right outcomes for and by the project.

 

What’s the problem?

TLDR:  There are challenges when using just one prioritization technique to provide guidance of what to work on next.

User stories and requirements can be prioritized using several different techniques (Ranked Order, MoSCoW, Scaled, $1/$100, High/Med/Low, Story Mapping, Weighted Shortest Job First [or WSJF], to name a few), with different benefits and drawbacks to each of them.

 

  • Ranked order, i.e., setting out to identify the explicit order to be worked, is a very time-consuming challenge. Changes, whether from business decisions or technical limitations, can happen at any time during the project and cause a reshuffle every time they occur.
  • Using fixed amount methods to prioritize, such as the $1 or $100 methods, are good at giving clear indications of importance by virtue of the highest number. Fixed values limit the number of stories that can be created without resorting to restructuring the whole valuation system. On reviews and revisits, any change forces a recalculation of many stories.
  • Categories produce multiple stories with the same value (many ‘High’ or ‘Must have’) that do not always provide enough information to know priority. When there are so many with the same value, it forces a break in the effort to know what should be worked on next, unless a tie-breaking method is already defined.
  • Story Mapping helps manage the big picture of the project since it displays all themes / activities of users. The themes and activities are ordered along a top row, then broken down into smaller stories and ranked in priority. Early in the project, the number of stories and ranking effort is focused, more easily identifying high value functions / stories.
  • Weighted Shortest-Job First, WSJF (pronounced wiz-jif), rates each story on business value, time criticality, and risk reduction / opportunity enablement (the business valuation, known as ‘Cost of Delay’), as well as factoring in the IT effort to deliver the story. With several criteria getting a valuation for each story, it becomes easier to see the highest business priorities to work on next. This can still mask the core needs that must be delivered.

 

Another challenge to prioritizing arises with many of these techniques when new stories are added. Sometimes a key requirement is missed during early analysis or through story decomposition and story splitting. Other times, demonstrations of work inspire new requests or research identifies a new need. How are the new stories valued, ranked, categorized? Do the newly added stories all get the same value as the original when split or does the ranking need to be done again? What becomes of highly valued stories which are just enhancements? Enhancements may have higher business value than some core technical stories. Some of these techniques handle additional stories more easily than others.

 

Maintaining prioritization is a challenge in itself

Capturing all this prioritization detail can be a frustrating challenge but maintaining it over time is just as frustrating. If you have a software tool that can automatically adjust rankings, some of these techniques may not be as much of a problem. But what if you are using physical cards or sticky notes to keep it all organized? It becomes a tedious task to manage the series, which will drive some to stop updating after a while, especially after repeated changes. Choose your method of prioritizing wisely, you will likely use it often.

 

Advertisement

 

How do we solve it?

Story Mapping is an effective approach to keeping an eye on the big picture goals without getting lost in the details. This is beneficial as it provides a more complete end-to-end view of the project, in addition to providing a view of the lower-level details in accompanying stories. Each of these stories can then be identified as a core ‘must have’ vs a ‘nice to have’ enhancement.

Combining multiple techniques simplifies project priority determination. For example, utilizing the business valuation portion from the WSJF does a good job identifying the value for any given story. The valuation can be used for easier ranking without the need to constantly revalue everything below (see Figure 1). In addition to identifying the value of each story, it is very helpful to identify what is needed for core delivery and what is enhancement. When splitting a story, make sure core functionality is clearly differentiated from what may be an enhancement.

Figure 1.

 

Taken in combination, stories are identified as a core delivery need or enhancement AND with each story’s individual business value (the number inside the ovals in Figure 1). While there may be enhancement stories with high value (sometimes viewed as the next shiny new thing), they may not be core functionality. Keeping the high-level view of core delivery items distinct from enhancements enables the focus to stay on outcomes. This perspective can be crucial to maintaining reasonable prioritization efforts in limiting unnecessary re-work of rankings, and identifying enhancement stories to address after all the core functionality is complete.

In the end, using more than one technique to manage project and product priorities ensures that the team is focused on getting the right overall outcomes, instead of persistent debate over individual stories. Practice quality communication and utilize your tool kit to experiment in finding what works best with your stakeholders and team.

 

BATimes_July28_2022

Think “Re-use” When Writing Requirements

Written by Adrian Reed on . Posted in Articles.

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.

 

Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page.  Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard?  This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world.  This is just one example.

 

Advertisement

 

High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow.  One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)

 

Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.

 

But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?