Tag: Requirements

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Written by Angela Wick on April 27, 2023. Posted in Articles.

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

Organizational risks
Missing stakeholders
Requirement gaps

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

Identify new stakeholders
Identify and mitigate risks/constraints
Redefine needs or identify new needs
Elaborate requirements
Prioritize requirements

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

Collaboration
Integration
Sharing of best practices

Keeping attuned to organizational changes can help to:

Mitigate risks
Estimate project deliverable dates
Manage scope
Identify constraints
Understand interdependencies

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

I ask the SME/s to describe the process for me.
Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
As they explain the process I ask, “What parts of the process would you improve and why?”
I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

Best of BATimes: The 7 Habits of Highly Effective BAs

Written by Priyanka Agrawal on April 26, 2023. Posted in Articles.

In my experience as a Business Analyst (BA), I have seen many analysts struggle in trying to strike the right levels of analysis. Some analysts tend to overanalyze while others, under analyze. Getting trapped in the dilemma of when to stop and/or when to continue analyzing can put you into a vicious cycle of ineffectiveness and devaluation. The result: zero business outcome yet a ton of frustration and a huge load of wasted time and effort.

The 7 habits of highly effective BAs guide you in establishing thresholds and protocols for your analysis finish line and helps you determine how far you are from the finish line. These 7 habits provide you with a compass that guides you to determine when to hit the breaks and/or when to accelerate your analysis.

1. Be cognizant of the allotted project budget and schedules. Create a mini work breakdown structure (WBS) for yourself that distributes analysis tasks and activities based on the allotted time and effort. Over time, you won’t need to formally put this down on paper and your mind will automatically signal you when you’ve exceeded or unfulfilled the allotments. However, be aware that this strategy alone may not help you in striking the perfect level of analysis. For best results, combine this technique with one or more strategies described below. For example, requirements analysis can be about 25-30% of an overall development project. If the analysis is taking more time than testing and programming put together, there is something evidently wrong. The flaw with this approach is that you will need to continuously monitor your project spend before you determine you’re on the wrong track which sometimes can be too late in the game to backtrack.

2. Establish and communicate success criteria at the onset to understand where the real finish line is. Once you have fulfilled the success criterion, you’ll know that you’ve more or less completed the required level of analysis.

3. When performing use case analysis, ensure you’ve considered not only normal and alternate flows but also exception flows. In my experience, at least 1 normal flow, 2-3 alternate flows, and 0-1 exception flows are typically enough.

4. Ensure you understand the inputs (preconditions), outputs (outcomes and postconditions), and actors before you start your analysis. This will help you say focused and on the right track in terms of scope.

5. Always refer back to the business objectives, goals, and vision. When performing any sub-activity, always ask yourself if what you are doing is related to, impacts or is impacted by the overarching goals. If the answer is no, stop! If the answer is yes, continue and go back to the success criterion.

6. Define limitations, assumptions, and constraints and keep those in mind all along when performing analysis. This will help you rule out some scenarios and help you continue on your journey to a fruitful analytical activity.

7. Know your audience. Ask yourself these questions: Who is the receiver of my analysis? Who would my work interest? Knowing who you are performing the analysis for will help you identify the level of detail required and therefore the amount of analysis to perform.

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on April 19, 2023. Posted in Articles.

In this article I want to explore how to integrate data requirements with product features and user stories; the result is some very useful traceability to where a particular data entity or attribute is being used across a product.

A conceptual data model is an integral part of the analysis process, it allows the analyst to better understand the overall requirement and how the various elements are related to each other. This enables the correct features to be identified to support the requirement and may well identify some gaps in the requirement where data is not being setup ready for the next process to collect and consume.

The data model will then naturally provide the start point for the database design and will ensure that all the features and associated user stories are all be singing from the same hymn sheet. The sprint teams will benefit from a shared understanding of the data that they are being tasked to manage.

The Tool

Initially my thoughts were that a true data modelling tool with a built-in dictionary were needed, having used these kinds of tools in previous projects.

As the choice of tool was limited, we explored whether Confluence might provide a useful stand in solution; we were already using Confluence to manage the requirements and user stories, so this looked like a natural plug-in to our existing Confluence wiki.

Develop the Model

For convenience, a separate data modelling space was setup to hold all the diagrams and page content for the data model which could then be referenced across the Wiki pages to add understanding to the requirements.

The Confluence service we were using came with the Gliffy diagramming tool; this allowed us to create entity relationship diagrams (class models). As the model was quite large, it was split into distinct data domains, this is easily managed by creating a view (diagram) for each domain.

Create Data Entities

In order to make the Confluence data model more like a true tool-based model, hyperlinks were included in the diagrams attached to drawing objects like an entity or domain; click on a high-level domain in the diagram view and the attached URL will then launch the associated domain view diagram, allowing a drill down to the detailed entity level.

Once down at the entity level, the next step is to setup each entity as a separate Confluence page; the last click at the entity level will arrive on a page that can be enriched with content for collaboration with the team.

Each data entity is loaded as a separate Confluence page; this approach also means that you can link to individual features and user stories using the page URL but also provides a ready-made folder to hold related content like data attributes.

Tip – Setup Data Domains

Setup a domain hierarchy in Confluence to file the entities appropriately, this will facilitate creating views of subsets of the model using the ancestor filter option in the reporting macro.

Trace Data Requirements

Now we have the model available in Confluence with each entity loaded as a separate page the data requirement can be integrated into the requirements wiki traced to the product features and included in user stories as a URL link to the relevant pages.

Tip – Identify Data Usage

The more comprehensive the application of this approach the greater value will be realised; if you go down to attribute pages then it will be possible to drill down to where data items are being processed.

Setup Data Attributes

Defining the data attributes is a useful activity to ensure that the system will include all the required data and manage it in a consistent manner.

Data attributes can be simple and self-explanatory items, the name alone can be enough to understand the purpose intended; however, it is often the case that the meaning can be very subtle and having an attribute page available to record an explanation is very useful.

Data attributes are setup as child pages to the parent data entity page to provide a natural filing plan but they can be referenced anywhere and shared in conversations with team members to clarify their purpose and ensure consistent data usage.

Tip – Attribute Names

Page names must be unique within a Confluence space, so it is a good idea to fully qualify the page name with the entity name as a prefix to avoid any duplication issues across different entities.

Integrate Data Requirements

This is where the data model becomes integrated and collaborative, a big advantage over separate modelling tools.

Whenever a user story is referencing a data requirement then the URL to the entity page can be plugged into the story as part of the narrative. For example, the narrative “Create a Customer record for the order received” can replace the plain text “customer” with a URL to the customer entity page instead. Once this approach is adopted the data usage can easily be discovered; starting from the entity page under the page information details all the incoming and outgoing links to the page will be shown, revealing where the data is used and with a single click the reader can jump straight to the story page.

Tip – Business Rules

Including attribute links in business rules will ensure the sprint teams are looking in the right place when implementing the user stories. For example, check the “order delivery date” has not be missed; otherwise, an alert must be triggered to follow-up on the delay with the customer.

Conclusion

Confluence may not appear to be the obvious tool to consider for managing data requirements; however, the fact that it can be integrated with the product features and user stories is quite powerful. The ability to see where individual data attributes are being used facilitates impact analysis and support; the business rules can be expressed precisely and facilitate the development of an integrated system.

It will require careful management to ensure changes can flow through the process and can easily be identified but this is true of all these kinds of tools.

Last but not least is a the record of feedback and comments added to the pages in Confluence, explaining why certain decisions were made and how data attributes introduced are being used by the system. This record will be invaluable for assurance and support queries to understand the how and why a piece of data is being used by the system.

Agile Requirements Management: The Art of Collaboration

Written by Steve Farrall on March 30, 2023. Posted in Articles.

In this article I want to expand on how to manage requirements, particularly focused on delivering user stories to development teams ready for sprint refinement sessions. The starting line is a set of requirements that have already been formulated and issued, for example as part of a tendering process for a new service or upgrade to an existing service.

The Tool

We adopted the Confluence wiki collaboration tool as it is well integrated with the preferred Jira sprint management tool from the same supplier, Atlassian. The objective was to build a knowledge base for the product that is sharable and retains useful insights posted by stakeholders and the project team; this will facilitate future enhancements but also be invaluable in answering the inevitable question – “Why did we do that?”

The start point is to load each requirement as a separate Confluence page; this approach means that you can link to individual requirements using the page URL but also provides a ready-made folder to hold related content. This has an initial overhead in loading the requirement pages but provides lots of advantages downstream, so its well worth the effort; we managed to load in excess of 800 requirements for one contract.

You may be thinking why not use a table embedded in Confluence page to hold all the requirements but this is hard to manage and you cannot easily address each requirement.

Tip – Setup Subject Areas

Setup a subject area hierarchy in Confluence and file requirements appropriately, this will facilitate creating views of subsets of requirements using the ancestor filter option in the reporting macro.

Trace Requirements

Add at least one trace for each requirement, one for each feature impacted by the change or new feature that will need to be developed.

In parallel, features can be added to the wiki, again as separate pages – one per feature; it does not matter that the feature page has little content at this stage, the aim is to have a place holder that is ready to receive content and will allow everything to start to become joined up.

If the feature is already in place, then you can just plug in the link in the trace page and you are ready to move forward.

Tip – Identify Impacts

Each impact will need a separate trace, however traces can be grouped together for delivery as a single story. Trace pages are filed as child pages to the parent requirement, so everything is kept together.

Validate the Solution

Validate the proposed feature changes with the Product Owner and SME’s, this is achieved using workshops and reviewing the trace page content and adding clarifications to pages during the sessions, so everything is up to date and immediately available to the team.

The sort of points to consider are – does the Product Owner agree with the introduction of a new feature or a change to an existing feature, are there better options to consider such as buying a third part add-in; these kinds of questions need to be answered before moving into a more detailed analysis of the requirements.

Tip – Agree Solution

Stories to be written are agreed before they are actually written to reduce the risk of wasted effort.

At this stage a story title may be added as a reminder to the author of what needs to be covered, this will then be replaced with the URL to the story page once it has been created.

The Collaboration Solution

I’m guessing by now people will be wondering how on earth will all those requirement, feature and trace pages be manageable once they have been loaded into Confluence.

This is where you can use a feature of Confluence known as the Decision macro, at first glance it does not appear to offer much – the ability to create logs of decisions to manage, so each decision is a separate page but you get a consolidated view that pulls them together – a bit like a spreadsheet.

The next step is to realise that requirements, traces and features are really just decisions – a decision to request a feature in a product, to deliver a product feature using an agile user story etc. The nice thing about decision pages is that they can be customised, we devised templates for each type of decision – requirement, trace, feature etc. So now we have logs of all our requirements, traces and features but each can be managed separately as a Confluence wiki page.

Tip – Setup Filters

Logs can become quite large, so the solution we adopted was to use the requirement subject areas to create filtered views that only included traces for a particular branch.

Create User Stories

Write the user story content to fulfil the requirements including the detailed process flows and business rules.

As stories may relate to multiple requirements they are filed in a separate branch and not under a specific requirement, they are still linked back to the requirement via the trace pages.

Tip – Story Content

Add as little or as much content to ensure that the requirement will be met including process flows and business rules.

This is more effective than trying to develop business rules once sprints have started.

User stories may be grouped together where a lot of stories need to be managed.

Validate User Stories

Check the proposed changes with SME’s, are the business rules correct, you may include mock-ups of user interfaces to facilitate the process and give context to the proposed changes.

Tip – Workshops

Workshops can be used to present user stories prior to development to mitigate the risk of the wrong solution being delivered.

Conclusion

Finally, we created a Jira ticket for each story and link it to the Confluence story page; Confluence is a better tool for content than Jira but they are both only one click away from each other. Click on the Jira link in the story page and you are taken to the Jira ticket and similarly you can navigate back from Jira to the Confluence story.

In fact, you can navigate right back to the requirement(s) behind each story, all the links will be setup and ready to use with no additional effort.

Don’t forget to update your feature pages with the story releases – cut and paste job mainly; otherwise, you will need to read through all the stories for a given feature, in chronological sequence, just to find out what it is currently meant to be doing in production!

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on March 2, 2023. 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.

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.