Tag: Agile

4 Tips for Managing Ambiguity as a Business Analyst

Written by Giorgos Sioutzos on April 17, 2024. Posted in Articles.

As a business analyst, it is common to face ambiguity in many different forms and aspects. It may be the ambiguity of the business analysis approach you have chosen, the requirements, or the design decisions that you have to contribute to.

Ambiguity and constant changes are something that is expected. It’s up to you to respond constructively. The following tips may help:

#1- Approve Ambiguity

Although you may want to have full control over the circumstances, it will not happen. It may take time and changes in order to establish a business analysis approach to customers’ needs or understand the full aspects of the system to be developed. It is fine not to have the full picture from the beginning of the analysis journey, but it is your job to progressively clear out the context and the scope. Approve the ambiguity of the intrinsic part of the analysis.

#2- Mindset Shift

Ambiguity can cause plenty of negative thoughts and worries. Instead of entering into a negative, endless dialogue, try to view ambiguity as an opportunity for new approaches, for innovation, and for gaining experience. Ambiguity can cause team members frustration and challenges, as the situations triggering it are mostly out of our control. It is important to reframe biassed thinking patterns concerning ambiguity into positive ones.

#3- Utilizing Effective Risk Response Strategies

As a business analyst, you should cooperate with the project manager to recognize factors and assumptions that can affect the business analysis objectives. You have to understand the sources of the risk and craft alternatives you can use if those risks actually occur. Whether you are a lead business analyst or other team member, your ability to identify and respond to risks effectively will affect the team’s ability to successfully complete project tasks.

#4 – Have a Compass

Having a specific compass for ambiguous situations is essential to guiding your decisions and actions. Orienting yourself and leading your team through a period of ambiguity can be supported by a stable and valuable foundation of personal and organizational vision, mission goals, and objectives. Knowing at any time why you are doing something and what you want to achieve and being true to yourself and your team can guide you as the North Stare in unpredictable and chaotic situations.

By viewing ambiguity as an opportunity, you can reduce the stress imposed by an ambiguous situation, experiment with new processes and ideas, and develop your team members. Identifying a goal or value that can be used as a “compass” can contribute to avoiding actions and behaviours you will regret later.

Don’t Let Your Software Requirements Die

Written by Chris Rickard on April 11, 2024. Posted in Articles.

In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential.

Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software’s lifecycle, promoting adaptability and precision in development processes.

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information – because often zero documentation is worse than out of date documentation!

How requirements slowly die.

Picture this: a new software project kicks off with energy and optimism. The business analyst dives deep, engaging with stakeholders to gather an amazing set of requirements. They craft an impressive functional specification that serves as the project’s North Star, and as the project kicks off, hundreds of tasks get populated into a project management tool like Jira, mapping out the journey ahead.

The software delivery team starts strong.

As expected, questions and clarifications emerge, evolving the requirements a little. Some tasks need tweaks; others have missing components, and there are even some sew requirements that surface. This is fine (we are agile after all!) – and these changes and additions are all added into the project management tool, as that’s now the source of truth keeping the project on track.

As the tasks are ticked off, a sense of accomplishment fills the air. Finally, the project crosses the finish line, the board clears, and it’s a wrap. Success!

Or is it? Software, particularly the large, mission-critical kind, is never truly ‘done.’

The project may have ended, but the software lives on, continuous adaptation and enhancement are normal these days. But scoping new tasks becomes a little harder, as the detailed system knowledge from that original functional specification, has now changed. The source of truth is now fragmented across completed Jira tasks and buried in comment threads.

In this scenario, the requirements didn’t just become obsolete; they died a slow death, leaving the team navigating a labyrinth of past decisions and discussions to grasp the full scope of their own software.

How to keep my requirements alive?

Keeping software requirements alive is pivotal for the long-term health and adaptability of your system. Rather than relegating these crucial insights to a static document, consider embedding them within a collaborative platform accessible to the entire organization. This living, breathing approach ensures that requirements can evolve alongside your software, reflecting real-time changes and decisions. Here’s how you can make it happen:

1. Centralize requirements and allow collaboration: Choose a platform where stakeholders across the business can access, review, and iterate on the requirements. This system should be the go-to source for everything related to what your software does and why, and platforms such as Userdoc are specifically tailored to this task.

2. Project management integration: While the main body of requirements should live outside, ensure there’s a seamless flow of information into your project management tools like Jira. This helps in translating the high-level requirements into actionable tasks and ensures day-to-day activities align with the broader goals.

3. Continuous updates and iterations: Encourage a culture where updating the requirements is part of the process, not an afterthought. This keeps the requirements current and relevant throughout the software lifecycle.

4. Embrace AI – AI can be an amazing tool for helping determine what changes could affect other parts of your system, and understanding that when writing requirements for New Feature X, you will also need to update Existing Feature Y’s requirements.

5. Requirements versioning: Just like with code, software requirements need versions and branches. Ensure you clearly denote what features are live, what features are in development, and what features are still being scoped.

6. Living reference for all teams: From development to QA, from business analysts to project managers, ensure that everyone references and contributes to the same set of requirements. This alignment prevents information silos and fosters a unified understanding of the system.

7. Long-term business asset: Beyond project completion, maintain these requirements as a living record of what’s in place. This becomes invaluable for training, onboarding, and new developers understanding the system’s capabilities and limitations. It also ensures the source code isn’t the only source of truth for the system’s functionality.

Transforming your software requirements into living documentation is a strategic move that pays dividends throughout the lifecycle of your software.

And the thing is, it’s not actually doing any extra work – it’s just simply unifying the place where that work is done, and fostering a culture of continuous collaboration and documentation.

Embrace the concept of living software requirements and watch your software, and team, move faster with more confidence.

Unveiling the Unsaid: The Power of Subtle Stakeholder Cues

Written by Adrian Reed on April 10, 2024. Posted in Articles.

When eliciting information from stakeholders, often what isn’t said can be as significant as what is said. Of course, the information that a stakeholder explicitly mentions is of crucial importance, but often there are subtle and nuanced details that aren’t obvious unless you look for them. Perhaps a stakeholder subtly pauses and looks uncomfortable and avoids answering a specific part of a question. Or perhaps they use a qualifying word like “usually” or “sometimes”. Either way, it is crucial to probe further and find out more.

Hearing What You Expect To Hear

Looking out for these clues is important, but is easier said than done, particularly when time is tight. When there are a number of stakeholders to speak to, it is easy to get drawn into a pattern of hearing what you expect to hear. We’ve probably all experienced this: after three people from different departments outline a process consistently, speaking to the fourth and fifth person seems like ticking a box. After all, they are going to just confirm what the first three people have described, surely?

That might be the case, but equally they might have additional insights that the original three did not. There is presumably a reason that they have been selected to participate in the elicitation activities, perhaps because they have a different perspective on things. Yet, it would be easy to let those discussions be swayed by the conversations that have happened before. To almost go on ‘autopilot’ and lead the stakeholder in a particular direction. It is worth being especially aware of those subtle cues and nuances in situations like this.

An Example

Imagine interviewing a stakeholder in a finance team about the invoice payment process. You’ve spoken to other stakeholders previously and you’re pretty sure you know the process:

“So, you get an invoice in, and as long as there’s a purchase order number on there, and as long as it’s approved, it gets scheduled for payment, is that right?”

“So, yes, mainly…. Yeah, mostly that’s it.”

It’d be easy to move on from this. It would be easy to assume that they are confirming some of the key decision rules (if an invoice has a purchase order number and has been approved, it gets scheduled). But the stakeholder has added qualifying words: mainly and mostly. These are easy to miss, but definitely require probing.

Probing might go like this:

“I noticed you said that this is mainly how the process works, are there other circumstances?”

“Yes, only very occasionally though. Sometimes, we get ‘proforma’ invoices that have to be paid immediately. We have a different process for those. Also, there are some cases where we pay up front by credit card. For example, booking training and conference places. That has a slightly different process too.”

Suddenly, a whole new set of facts becomes available. If this were a real situation, this would lead to further probing (e.g. “Are there any other times when the process operates differently?”, “Is there just one corporate credit card, and if so who is responsible for it” etc, etc).

Make Sure They Feel Heard

Of course, probing this way is important to ensure that nothing crucial is missed. However, genuinely listening is important for another reason too: to ensure that people actually feel heard.

If you’ve ever had the experience of speaking to someone who appears to be preoccupied, and is perhaps presuming what your responses are, you’ll know that this rarely feels great. As analysts, it’s important that we empathize with and genuinely hear what people are saying.

Listening in this way will help uncover important information. It is a crucial and often taken for granted skill, but one that we can probably all hone and improve upon!

Five Ways BAs and Inventory Managers Can Make Jobsites More Profitable, Together

Written by Lucas Marshall on December 13, 2023. Posted in Articles.

Business analysis is a critical skillset and operational imperative companies need to prioritize as they look to be profitable and understand how they can make measurable improvements as they scale. This fact is not lost on corporations, either—for example, 72% of manufacturing executives said that they considered advanced analytics to be important, according to a report by BCG.

The construction sector, meanwhile, consistently finds itself in a precarious state in terms of profitability no thanks to employment challenges, influx materials pricing, and the disjointed nature of the construction ecosystem. For example, experts estimate job growth in the construction industry is projected to be at a stagnant 1.1% for ten years (Data USA via Finances Online). Underperformance, Autodesk concludes, is an industry-wide norm with 72% of firms saying projects have taken longer than anticipated—and 44% of firms putting longer completion times into their bids, according to data from Associated General Contractors of America (AGC). In fact, merely 25% of projects came within 10% of their original deadlines, a KPMG report found.

The World Economic Forum (via Autodesk) estimated that a 1% reduction in construction costs could save society $100 billion globally. As the construction sector ecosystem looks to execute projects in a quickly changing environment, these existential challenges warrant organizational changes to better negotiate the trials and tribulations at hand.

We also have to consider the average construction company’s costs to better contextualize these challenges and opportunities. If we assume that the average cost of a construction project is comprised of overhead, materials, tools and equipment, and labor, then focusing on what you can control will help move the needle toward greater profitability. For example, while you might not be able to affect the cost of materials, you can negotiate work to accommodate the resourcing you currently have, and you can make plans for improving internal processes to drive greater efficiency.

I’ve previously written about how project managers in the construction industry should embrace change management, as well as how the industry might adopt big tech’s displaced software engineers to address industry digitization problems, and how the construction industry looking to adopt lean management principles may borrow some of the similar practices from agile software project management.

Studies show that business analysts are more prone to support collaboration in agile projects.

With this in mind, in this article, I look to unpack two roles—the Business Analyst and the Inventory Manager—and discuss how a collaboration matrix between these roles can help construction companies work leaner, more efficiently, and drive greater profitability over time.

The Role of the Business Analyst & Why BAs May Be a Critical Construction Industry Hire

Considering construction’s profitability concerns, the role of a business analyst (BA) from the corporate environment is one that construction companies may look to fast-track.

Responsible for “bridging the gap between IT and the business using data analytics to assess processes, determine requirements, and deliver data-driven recommendations and reports to executives and stakeholders,” a BA in a construction company setting can “offer valuable insights to enhance financial planning and resource allocation,” reads the job description for a Senior Construction Business Intelligence Data Analyst role at CBRE Group, a global commercial real estate company, which was available at the time of writing this article.

Consider CBRE’s job posting for some of the job-specific functions a Business Analyst in the construction industry may entail:

Applying advanced analytical techniques to conduct prescriptive, diagnostic, descriptive, and predictive data analysis on diverse construction-related data, incorporating data from Quickbase, eBuilder, SAP, and Google Sheets.
Developing dashboards, meticulously maintained [… that] provide real-time insights into construction project data while ensuring these dashboards are user-friendly, intuitive, and deliver vital information to project collaborators (e.g., stakeholders).
Generating regular and ad-hoc reports for the leadership team, highlighting essential performance indicators, project status, and emerging trends, while translating sophisticated data into practical, actionable insights, incorporating earned value measurement concepts to evaluate project performance.
Providing meaningful support for annual capital planning by conducting comprehensive analysis of historical data, project costs, and resource allocation, offering valuable insights to enhance financial planning and resource allocation.
Developing and maintaining strategic forecasts for construction projects, demonstrating data analytics to identify trends and make informed predictions about future outcomes, incorporating earned value measurement techniques to assess project performance and forecast project completion accurately.
Providing data-driven insights that support critical business decisions, helping to improve operational efficiency and profitability.

Construction forecasting is one critical business process a business analyst may help owners more accurately predict through advanced analytics, historical trends, and advanced technology management (e.g., artificial intelligence).

When they collaborate with other critical business functions (e.g., inventory management, discussed next), greater outcomes may become more easily within reach.

The Role of the Inventory Manager in Construction Projects

An inventory manager in the construction industry (aka: tool crib manager, tool room manager, asset manager, equipment manager, etc.) is responsible for the strategic direction, allocation, storage, and flow of all the physical assets needed to perform construction work—e.g., building materials, tools, vehicles, and equipment.

An inventory manager assures jobsite materials, tools, and equipment arrive on jobsites as they’re needed, are in working order (e.g., tools are properly serviced, materials are not damaged, etc.), and are returned or rerouted across projects as needed to prevent slippage and excess asset turnover.

With an inventory manager at the helm of the construction supply chain, companies might realistically see a 10-12% reduction in labor cost originating from avoiding non-productive idle time or downtime—that is to say, when materials are where they’re needed, manpower doesn’t need to search for them or idly wait for their arrival.

How BAs and IMs Can Work Collaboratively to Drive Better Profitability Outcomes

Now that we’ve discussed what a Business Analyst role may look like in the construction sector, as well as the role of an inventory manager in the same sector, how might these cross-functional teammates work together to drive better profitability outcomes?

Here are five ways:

1. Procurement Strategies

A business analyst, tied into company forecasting, can work closely with inventory managers to establish objectives for procurement strategies and capital investment as well as determine needs based on ongoing inflight projects and company annual goals.

Together, they might reasonably achieve strategic themes when approaching inventory-related financial commitments and implement cost-saving measures, including:

Appropriate Safety Stock Purchasing – Together, a business analyst and inventory manager can cross-pollinate company-specific analytics related to equipment purchasing, historical trends of project needs, and existing commitments in order to reasonably define policies for shelving inventory and planning for needs (i.e., how much to buy, when). Such a collaboration can help prevent excessive inventory procurement that would otherwise lead to unnecessarily rising overhead, while it can also help facilitate proper procurement to prevent inventory stockouts. What’s more, using advanced analytics via artificial intelligence can help predict future needs.
Proactive Inventory Audits to prevent needless spending over project lifecycles as well as to provide better long-term inventory management outcomes.
Deploying cost-centric, advanced inventory management strategies like just-in-time inventory. This method prioritizes strategic, lean operations in order to deploy only what’s needed when it’s needed, preventing excessive inventory procurement (and like above, preventing unnecessarily rising overhead). The method also requires inventory managers to proactively intervene to prevent jobsite hording, hence why inventory tracking (e.g., Bluetooth tags, GPS trackers, etc.) is critical.
Performing XYZ analysis to calculate: fixed demand (X), fluctuating demand (Y), uncertain demand (Z). Determining these inputs can help inventory managers more effectively achieve more positive outcomes by ranking the frequency and predictability of demand for items over time.

2. Job Costing

In addition to financial forecasts and reporting, business analysts can work with inventory managers to adopt a job costing solution. Job costing in construction refers to the proactive process and steps taken to track the associated costs and revenue of a given project throughout its lifecycle.

The process can be used in inventory management, where inventory managers can apply rental rates (daily, weekly) to equipment that is deployed to the field (either individual or bulk inventory that’s been kitted/bundled and sent at once). Job costing software then calculates the cost accrued for each day (or week) those items are in the field.

This process can help:

Inventory managers better account and monetize on the equipment they send to their network of jobsites.
Financially incentivize borrowers to return equipment in a timely manner, reducing the “time on site” of a particular piece of inventory as well as the need for additional safety stock, unnecessary rerouting of equipment from other jobsites, etc.
Provide additional revenue streams to construction businesses.

3. Reporting

In addition to the business analytics dashboards that a construction business analyst might build for a business owner as discussed in the above-mentioned job description, inventory managers can work hand-in-hand with business analysts to provide additional reporting opportunities, including:

Tool Management Reports – reports about ongoing usage of inventory (e.g., average “days on site,” as we discussed above, to help make improvements on how inventory is used in the future; service-related alerts, to help proactively take charge of equipment maintenance, improve longevity, and decrease overhead; inventory assigned by jobsite or person, to increase accountability; etc.)
Asset-specific reports, such as utilization on some smart power tools, which can help diagnose problems before a jobsite-halting breakdown occurs as well as provide quality assurance to customers and inspectors that installations were performed to specification.

4. Interoperability

Construction interoperability is the practice whereby construction systems (e.g., software platforms, apps, processes) interact with each other and the extent to which they possess the ability to operate seamlessly and share information between each other.

A KPMG report revealed that only 16% of executives surveyed say their organizations have fully integrated systems and tools—a serious problem when we consider how fragmented the construction ecosystem is. Consider, too, that only 36% of firms have implemented a process for identifying bad data and repairing it (Autodesk/FMI report).

Together, inventory managers and business analysts can start to build system interoperability that can both provide a single source of truth and prevent cost driving incidents like rework (e.g., from the same Autodesk/FMI report, 14% of all construction rework may have been caused by bad data, creating $88.69 billion in avoidable rework globally).

Possible interoperable systems include:

Connecting data flow between a project management system (e.g., Procore, Autodesk Construction Cloud, Contractor Foreman, Houzz Pro) and architecture, design, and civil engineering (e.g., Revit, AutoCAD, SketchUp, Bluebeam, Autodesk BIM 360, Civil 3D, ArcGIS, Bentley STAAD, etc.)
Connecting data flow between inventory management systems and mission-critical systems (e.g., project management, design, etc.)
Building digital twins (e.g., asset twins, component twins, system twins, process twins) to provide holistic views of cross-network activities, predictive analytics, and real-time data and simulations to aid in decision-making.

5. Planning for Addressing Technical Debt

Technical debt is a phenomenon whereby dependencies one introduces when deploying new software and hardware solutions lead to operational slowdown.

A colleague and I have outlined five ways construction companies can prevent technical debt. A business analyst and/or construction technologist may work hand in hand with an inventory manager to prevent technical debt relative to construction operations from piling up – e.g.,

They may work with IT to deploy cloud-based systems (i.e., real-time collaboration).
They’ll deploy inventory tracking hardware to ensure real-time inventory activity is recorded.
They’ll ensure mobile apps integrate with construction ERPs.
They may work with the cybersecurity team to ensure proper MDM deployment and data security best practices relative to inventory.

Bottom Line

The construction industry faces some dire operational challenges.

While construction companies might not be able to affect the cost of materials, they can focus on factors they can control—e.g., improving internal processes, empowering the team to work more seamlessly together.

When working collaboratively, business analysts and inventory managers can help companies operate more agilely, more strategically focused, and they can help achieve greater profitability over time.

How Product Discovery Deals with Requirements

Written by Nuno Santos on October 4, 2023. Posted in Articles.

If you are working in products, you certainly have realized product management handle requirements differently. There is a shift from eliciting stakeholders’ wishes to discovering better and faster ways to solve stakeholders’ problems. This article presents how discovery techniques popular within product management fit in the three types of requirements: business, stakeholder and solution. Understanding where the techniques fit in this spectrum will allow a better understanding of how and when to use them.

Keywords: Requirements; Elicitation; Product discovery

What is Product Discovery and this “Modern” Elicitation

There may have been times in the past where business analysis was (incorrectly) seen as a passive discipline. Some might have viewed that a business analyst’s job when “gathering” requirements, most of the time, was attending meetings where they interviewed a group of people. Typically, these people had significant roles in the product (although most of the time they wouldn’t be the future users of the solution) and the business analyst would simply be a clerk and register all their dictated “wish list” items.

This approach is based on the premise that your sources know what they need and dictate the solution, yet how often is this actually realistic? More often there will be experimentation, change and the need for flexibility. The emergence of agile development methods and frameworks like Dual Track Agile, influenced organisations to split their efforts into product discovery and delivery.

The main shift on the premise of product delivery, compared to bespoke or market-driven requirements engineering, is that teams have to discover what the user’s problems are based on a set of assumptions and validate if a delivered solution contributes to the desired outcome. For business analysts, this means being involved in both the discovery and delivery processes, and it requires a shift in how requirements are elicited and managed. BAs need to challenge stakeholders’ perceptions on any assumed solutions and get to the underlying need using modern requirements techniques. They have to discover the requirements rather than gather them.

The Requirements Engineering Cycle

The cycle that typically involves elicitation, documentation, validation, and management of requirements is often associated with the broader field of Requirements Engineering or Requirements Management within the context of software development or project management. This cycle is iterative and continuous throughout the project lifecycle. Here’s how it works:

Elicitation: Requirements are gathered from stakeholders, users, and other relevant sources. This step involves understanding their needs and expectations for the software or project.
Documentation: The collected requirements are documented in a clear and comprehensive manner. This documentation can take various forms, such as a Software Requirements Specification (SRS), user stories, use cases, or other requirement documents.
Validation: The documented requirements are then validated to ensure that they accurately represent the stakeholders’ needs and are feasible to implement. This involves checking for consistency, completeness, and correctness of the requirements.
Management: Throughout the project, requirements are actively managed. This includes change management to handle updates or modifications to requirements, traceability to link requirements to design and testing, and prioritization to determine which requirements are most important.

The requirements process doesn’t end after the initial elicitation, documentation, and validation. It’s a continuous and iterative cycle because requirements may change over time due to evolving project goals, stakeholder feedback, or other factors. Therefore, effective management of requirements is essential to ensure that the project remains aligned with its objectives and stakeholder expectations. It often involves feedback loops, revisions, and ongoing communication with stakeholders to refine and adjust requirements as needed throughout the project’s lifecycle.

1. Discovery Techniques for Elicitation

“How might We…” Technique

The “How Might We” technique is a crucial aspect of the design thinking process and is often used in design sprints to frame problem statements and generate creative solutions. The “How Might We” technique involves rephrasing challenges or problem areas into open-ended questions that invite elicitation through brainstorming and creativity. The challenge is to rephrase it as an open-ended question that begins with “How might we…?” The “How Might We” statements invites participants to generate creative ideas without feeling restricted by existing limitations. It shifts the focus from problems to possibilities, and it helps teams explore solutions from different angles, often leading to innovative and unexpected outcomes.

Jobs-To-Be-Done

“Jobs-To-Be-Done” (JTBD) encourages us to appreciate why a product or service was “hired”, not only in a functional dimension, but also in circumstances and emotional dimensions. The book “Jobs to be Done – Theory to Practice” by Anthony Ulwick describes a framework that you can use to define your jobs, from setting your different customers, the different kinds of jobs (core, related, emotional, consumption chain and purchase decision jobs), and setting the desired outcomes.

The behaviours of the customers that afterwards lead to definition of the “hired” job are identified by observation. Observation is a common elicitation technique. In this case, rather than observing (or shadowing) in order to replicate a given process, an observation within JTBD aims to relate a behaviour to customer’s outcomes.

Continuous Interviews

Teresa Torres described a set of “continuous discovery habits” to engage customers in a continuous cadence. The main shift in doing interviews is that questions don’t focus on what customers want. Rather, questions should focus on their past experiences to discover an opportunity.

As the name states, it uses interviews techniques. Once more, a very popular way to perform elicitation. As mentioned, the main shift is that questions that are asked focus on their past experiences to discover an opportunity.

The Mom Test

the Mom Test is another interesting approach for conducting stakeholder interviews. It has similarities with “Continuous Discovery Habits”, as the questions should focus on their past experiences to discover an opportunity. The premise of the Mom test is: your mom will always like your idea, but doing the right questions can make her tell what you really need to hear. Elicitation by performing these kinds of interviews allows us to depict the problem in question, rather than waiting for the interviewees to tell us the solution they want.

2. Discovery Techniques for Analysis

Value Proposition Canvas

The Value Proposition Canvas is a strategic tool used in business and product development to understand and communicate how a product or service creates value for customers. It’s typically used in conjunction with the Business Model Canvas to create a holistic view of a business. The canvas helps businesses design their offerings by gaining a deep understanding of customer needs and how their products or services fulfil those needs.

It demonstrates a clear understanding of customer pains, gains, and jobs to be done, and introduces alignment of the pain relievers, gain creators, and product(s) benefits.

User Journeys

User journeys, also known as customer journeys or user experience (UX) journeys, are a product discovery technique that originated from the field of User Experience Design (UXD) and User-Centered Design (UCD). User journeys provide a visual representation of the user’s interactions and experiences while using a product or service. They aim to capture the user’s perspective, emotions, actions, and touchpoints across different stages of their interaction with the product.

Opportunity Solution Trees

Opportunity s olution t rees are a visualisation of potential solutions to a customer problem. They involve breaking down the problem into smaller opportunities, generating multiple solutions for each opportunity, and then evaluating and selecting the most promising solution.

It is our analysis work in getting insights from conducting the Continuous Interviews, allowing us to identify opportunities for our product.

3. Discovery Techniques for Documentation

Epic Alignment

“Epic alignment” is from Nils Janse’s book with the same name, proposes a single source of truth about the requirements, in form of a “lightweight” documentation that is based around epics. The structure that is proposed for this documentation includes information that is incrementally added to what we know about a given epic throughout the product development stages (namely, Ideation, Discovery, Prioritization, Refinement, Development and Testing). The structure of these documents allow to follow the information about an epic, which user stories are included, and the details that are needed for their implementation.

4. Discovery Techniques for Validation

User story mapping

The last technique I want to discuss in the article is u ser story mapping. This is a technique where team members collaboratively discover how a set of user stories solve a customer problem. The method consists of sequencing the user’s activities, and allows further elicitation to take place so that detailed stories and tasks can be captured. This in turn ensures that the solution will support the user’s activities that were presented.

Classifying this technique in a single stage can be tricky. I rather believe it encompasses elicitation, analysis and validation of requirements.

It’s a technique where team members collaboratively discover how a set of user stories solve a customer problem. End users may be involved in the collaborative process as well, most probably giving inputs in the user journey and the sequence of activities – which makes it an elicitation technique. Sequencing activities may be an output of previously performed elicitation, resulting from analysis of that information. Lastly, acceptance criteria may be included in the details of the story mapping, which forces the team to start stepping up into the requirements validation. In the case of users not have been part of collaborative process, the model may be used to validate together with users that the user journey is indeed correct.