Tag: Requirements

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.

Prioritizing Requirements: An Analogy

Written by Eileen Raycroft on March 1, 2023. Posted in Articles.

I work with “business sponsors” in my company. Some of them are old hands at going through the process of requesting a new application, or a rewrite, or enhancing an existing application. Others, though, may never have been involved in requesting software, whether it’s a custom-built application, or something offered by a third party vendor. In any case, it can be daunting to make decisions about what to ask for, especially when they have to submit a request to get the money to proceed.

Most people I know enjoy engaging in “blue sky” conversations – if you had all the resources in the world at your fingertips, what would you like this new application to do, to support what you and your clients need? And to be honest, I enjoy those conversations as well. It’s fun, and liberating, to just let your imagination take flight and ask for the world! At the end of those blue sky sessions though, it’s time to bring ourselves back to reality, look at the lineup of desired requirements, and put a priority on each of them. And one of the prioritization methods I’ve had the most success with is the MoSCoW method.

MoSCoW Prioritization Categories:

M = Must Have. Non-negotiable needs that are mandatory for the business.

S = Should Have. Important features that are not critical but have much value.

C = Could Have. Nice to have features that will not impact the usability of the application in a detrimental way if they are not included.

W – Will Not Have/Wish. Features that should be placed in the product backlog for future consideration.

I often use analogies to drive home various concepts to my stakeholders, especially if it is something they aren’t familiar with. Analogies help them grasp these concepts more quickly, rather than using a lot of “wordy” explanations. I use this analogy about prioritization when appropriate.

How to Research buying a Refrigerator

Recently my husband and I purchased a new refrigerator. Our old one was on its last legs, and we wanted to purchase a new one before the old one gave out at a most inconvenient time, as we had experienced several times in the past! (If you’ve ever had a fridge give out on you when you had a great load of food in it, you know the stress I’m talking about!)

Since it had been quite a few years since our last purchase, we started looking around and were astonished at all of the new configurations and features that were available in new fridges. The price tags too, had changed – wow, were they expensive!! So, I said to my husband, “Why don’t we write down all of the features we think we would like in a new fridge, and then go shopping with that list?”

So we sat down at the kitchen table with our son, who lives at home (gathered all the stakeholders), and I started the list of “requirements” for our new fridge. Did we want an ice/water dispenser, which our old fridge had? What about extra room for vegetables, now that we had committed to eating more healthy? How many cubic feet of space did we want? How about a deli drawer? Or a computer on the outside of the fridge?

Feature	Prioritization
Ice maker/dispenser	M
Maximum room to store vegetables	M
Minimum cubic feet 26 cu ft	M
French door style	S
Deli drawer	C
Energy efficiency	M
Computer built in the front of the fridge	W
Etc.

Once we had our list written down, we used the MoSCoW technique of prioritization, and each requirement was given a must-have, should-have, could-have and won’t have/wish. We also had to figure out what our budget was–not many people have infinite resources, and we are certainly not in that league, financially!

So, armed with our requirements and our budget number, we started shopping. On-line, and in person, we spent many hours researching the available options. Some of those could-haves and wishes dropped off the list pretty quickly, because although we had what we felt was a moderate budget, it certainly weeded out the more extravagant models.

We were able to find a refrigerator that had all of our M, S, and most of our C items in our list that was within our budget. And because of all this work we did in advance, we actually felt good about our purchase—we were very satisfied we’d made the best choice for us. That didn’t mean we got everything we wanted, but we didn’t feel disappointed. We’re still loving this fridge three years later.

Conclusion

And that’s exactly the feeling I want my business sponsors and stakeholders to feel – very satisfied that they’ve made the best decisions for the application/enhancement or whatever the initiative is. Do your research, prioritize your requirements and move forward with confidence.

Deep Listening: Avoid Hearing What You Want To Hear

Written by Adrian Reed on February 16, 2023. Posted in Articles.

Elicitation is a key business analysis skill. Whether it’s one-on-one interviews, workshops, observation or one of the many other techniques, elicitation is a key source of information. As BAs, it’s easy to think that we are highly attuned listeners, carefully scouring the airwaves for tasty morsels of relevant information. Of course, this is probably true. However, have you ever reflected on how deeply you pay attention and listen? For example, have you ever:

Quickly checked your email in a meeting (where something critical could be mentioned, but you weren’t expecting it)
Been tired at the end of the day so tried to rush a conversation
Skim-read an email and missed a key detail
Missed a key piece of information in a document
By the time you interview the sixth person, you think you already know the answer so ‘tune out’ for part of the interview

If you haven’t, then you probably deserve a medal. I’m sure most of us have indulged in some—or all—of these behaviors at some point in our careers. While there might be good reasons to do so in some cases, doing so will affect the ability to listen deeply. Notably, by ‘listening’ here, I’m also referring to ‘reading’ of information, as I suspect we all spend a lot of time ‘listening’ to our colleagues through their emails and comments on documents etc.

Miscommunication Is Rife

It’s easy to miss the point when listening or reading. As an example, I was wandering around a large supermarket here in the UK, and I picked up a bottle of own-brand hand wash. I was looking on the back of it, and noticed the following statement in bold:

[Supermarket name] is against animal testing and funds alternatives

It struck me that this is a deliberate piece of misdirection. If you were scanning it quickly to look for information about whether the product is tested on animals, you might see that statement and think “oh, they’re against animal testing, so it’s fine”. This is similar to a case where a listener hears what they expect to hear, or what they want to hear! However, the statement taken at face value doesn’t confirm (or refute) whether the product was (or wasn’t) tested on animals. It just says the supermarket is against animal testing and funds alternatives. Yet many readers’ might inadvertently apply their own meaning to it.

Granted, you’re unlikely to be reading a statement on the back of a hand wash bottle at work, and it’s unlikely that folks will be deliberately trying to deceive. But it’s very easy to miss tiny nuances in verbal or written communication. Take these statements:

“I broadly agree with what is proposed” (what does broadly mean? Are there areas of disagreement? If so, what are they?)
“I agree with points 1 and 3”. (OK. Do you disagree with point 2?)
“This is a real pain point for us.” (What does ‘pain point’ mean? Does our definition of ‘pain point’ agree with theirs?)

These are just three specific examples, but I’m sure you get the point.

Curiosity Is A Prerequisite To Listening Deeply

Deep listening is hard, and a skill that one could probably work on for their entire life. I have heard it said multiple times that people tend to listen to respond; by the end of the speaker’s sentence the listener is tuned out thinking how to respond. As a BA, this might translate into thinking about the next question.

It is almost as if we are scared of silence. Like silence will be interpreted as some awful slight on our stakeholders. Yet in reality a (relatively short) amount of silence can be useful. In my experience, people will often pause, reflect, and add more insight when given a bit of breathing space. Of course, what is considered an appropriate length of silence varies, and certainly it shouldn’t be excessive!

A common thread throughout this is curiosity. If we are genuinely curious about the stakeholder, the subject-matter, their perspectives and so on then it’s easier to focus in and listen. If we lose curiosity or get distracted by the busy-work of organizational life it’s far too easy to tune out.

Here’s to remaining curious, and to listening deeply!

How to Safely Escape from the Assumption Trap in Requirement Analysis?

Written by Sumi Prasad on February 1, 2023. Posted in Articles.

There is a saying “Assumption is the mother of misunderstandings”. With that being said, it is common for business analysts to make assumptions to move forward with the requirements analysis. Because assumptions can help improve the efficiency and effectiveness of requirement analysis, reduce uncertainty, and identify potential risks, if not properly managed and communicated, It can become a double-edged sword.

Let’s evaluate,

What are assumptions in business analysis?

Assumptions are statements without evidence or verification that are accepted to be true.

For instance, assuming that the new software will be compatible with existing hardware and operating systems. Or assuming that the user will find the new feature easy to use or assuming that the product will meet non-functional requirements, such as security and accessibility.

Based on the business, context, time, customer, process, etc. assumptions can vary. Some examples include the following:

Assumptions about the customer: their needs, motivations, preferences, market segments.
Assumptions about the requirements/problem: nature, impact, pain points, tasks involved.
Assumptions about internal resources: culture, technical capabilities, time, budget, availability.
Assumptions about the solution: ease of use, UI design, technical constraints, functional and non-functional aspects.

What are the advantages of making assumptions in requirement analysis?

Enhance the efficiency and effectiveness of requirement analysis by focusing on the most critical and relevant aspects.
Ensure that scope is confined and complexity is avoided.
Provide better insight into the customer’s requirements. Considering different scenarios and making educated guesses can help in gaining a deeper understanding of the customer’s needs.
Create flexibility in the process of gathering requirements. As such, ability to adapt to changing circumstances and respond better to unexpected challenges and opportunities that may arise during the development process.
By documenting and communicating assumptions, stakeholders and team members can ensure that everyone is on the same page, making informed decisions.
Identify potential risks during the discovery phase and avoid surprises at the last minute.
Reduce uncertainty by allowing analysis to continue even if you don’t have a complete picture

What are the downsides of making assumptions in requirement analysis?

If assumptions are not clearly stated or communicated, it can lead to misunderstandings among stakeholders and team members. This can result in misaligned expectations and rework.
If assumptions are made with biases for example the business analyst assumes that the stakeholder has a certain level of knowledge or understanding, they may use technical language or make assumptions about the stakeholder’s needs without verifying them, which can cause misunderstandings of the requirements.
If assumptions are not clearly documented or communicated can lead to confusion and a lack of clarity about the requirements. This can make it more difficult for the product team to accurately plan and execute the project.
If assumptions are not properly addressed, it can result in incomplete requirements, which can lead to issues during the development phase. For example, if a key assumption is not considered, it could result in the development team building a solution that does not fully meet the needs of the users.
If assumptions are not properly managed, it can increase the risk of project failure. For example, if an assumption about the availability of resources turns out to be incorrect, it could lead to delays or other issues that impact the schedule and budget.

The above list of downsides is presented using an “If” statement intentionally in order to emphasize that making assumptions is not a pitfall but rather an important part of requirements analysis and gathering. It becomes a problem if not effectively managed and communicated with the stakeholders.

Business analysts should be explicit about their assumptions and verify them with relevant stakeholders. Various techniques can be used to accomplish this, such as asking questions, using user stories to describe requirements in detail, and involving the customers in the requirement gathering process.

Some tips for effectively managing the assumptions that you are making during the requirement analysis.

Spend time and critically evaluate the assumptions that you are making as you progress with the analysis.
Write down the assumptions that you are making in a concise manner at all stages. This will help to ensure that they are easily understood by others and can be referred back to later.
Make sure to communicate the assumptions that you have documented with the relevant stakeholders.
Review the assumptions that you have made to ensure that they are still valid. If any assumptions turn out to be incorrect, be sure to update them and communicate the changes with stakeholders.
Mention date when documenting the assumptions, which will help to review and validate the assumptions at later stage (E.g.: As of <date>, At the time of writing <date>, As at the <date>, At the <date> of writing/drafting/reporting).
It is important to be proactive in asking questions and verifying understanding, and to be aware of one’s own biases and seek out diverse perspectives.
There are times when assumptions are made unknowingly or by overlooking certain factors. It is possible to uncover such hidden elements through careful analysis and attention to detail. No matter how obvious and straightforward something seems, it still needs to be mentioned. In some cases, simple statements and questions can reveal hidden assumptions.
Make realistic assumptions. For example, assuming that the new product will be 100% efficient with no waste or errors is unrealistic.

To summarize, taking assumptions into account is an essential element of business analysis because it simplifies problems and accelerates analysis. Nevertheless, it is imperative to understand the pitfalls of assumptions and carefully consider their validity. Explicitly acknowledging, managing, communicating, and reviewing assumptions helps businesses minimize the risk of making inaccurate decisions.