The adoption of agile principles within some of today’s organisations provides the enterprise with the capabilities to react faster to market fluctuations, improve process efficiency, increase customer satisfaction, and create a more relaxed working environment.
To help enable this, the business analyst in agile can apply various agile business analysis techniques and apply agile business analysis best practices that emphasise customer collaboration, team working and enabling business outcomes. Determining which agile business analysis techniques are suitable for a specific project requires a certain degree of experience and knowledge.
Depending on a context, accomplishing the desired outcome can call for the use of a combination of several different agile business analysis techniques. Also, the same technique can prove to be useful in a variety of contexts. We’ll take a closer look at the best practices for business analyst in agile working environment to compliment a business analyst toolkit.
We have another article if you are interested in some of the more traditional business analysis techniques
.
Table of Contents
Backlog Refinement
One of the necessary conditions for the delivery team to successfully complete an iteration is a clear and suitable detailed backlog. This agile business analysis technique is used for maintaining backlog is backlog refinement and it should be performed continuously throughout the project until a certain backlog item is delivered. The maximum value delivery is ensured by constant revisiting and refining of the stakeholder’s needs. Logically, the backlog refinement is mostly based on the stakeholder’s feedback.
This technique includes prioritising or even complete removal of the items from the backlog if deemed necessary. The backlog refinement activities can include or overlap with other agile techniques such as story splitting or story elaboration. The backlog item is refined when there is enough information for execution by the team.
Backlog Refinement includes the following elements:
- Backlog – a sorted list of features, requirements, or items necessary for solution delivery;
- Backlog item – items listed in the backlog representing certain requirements. Higher placed items are usually more detailed and ready for completion, while lower items on the list are more robust and less defined;
- Refinement meeting – a meeting, usually led by a product owner where the items on the top of the backlog are discussed and evaluated for their readiness for the next iteration;
- Definition of ready – the item is deemed “ready” if it satisfies the set of criteria agreed upon by team members. These criteria can be modified or expanded as the process moves on.
The strengths of the backlog refinement technique are that it improves the understanding of a backlog item, provides more effective iteration planning, gives chance to the product owner a chance for necessary clarifications before execution, and ensures the proper sizing of backlog product items.
The limitations include inefficiency when unaligned with the team’s cadence, exclusion of the uninvolved team members from the process, and the lack of effectiveness when the vision changes frequently.
Behaviour Driven Development (BDD)
Behaviour Driven Development (BDD) is a technique based on real examples employed to identify the solutions of value to the customer, improve communication, and avoid waste.
This is done by specifying the customer’s intended behaviour that satisfies a certain need. It allows for a more efficient solution development process by concentration only on things that are needed.
This agile business analysis technique helps the product owners to better communicate the ideas by using real examples. By asking “what if” questions, business analysts discover alternative scenarios and provide additional examples.
The examples are better understood than the abstract models and lead to close collaboration of team members.
Behaviour driven development includes the following elements:
- Examples – business analysts use examples that are based on real life scenarios and they can be presented in various ways, including models. The better the examples are defined and the more extensive they are, the easier will be to discover new information;
- Gherkin syntax – BDD is expressed using a simple grammar format known as gherkin. It’s in the syntax form of
- GIVEN
- WHEN
- THEN
- Testing – the examples of this kind can be easily converted into automated tests using several software applications. This leads to more agile delivery.
The advantages of the behaviour driven development include an easy understanding of customer’s needs, direct implementation of results through test driven development, production of effective product cases, long-term and flexible documentation, easily prioritised scenarios, and the ability to support structure design discussion focused on particular behaviours.
The disadvantages are potential missing of the important scenarios, lack of ability to handle multiple scenarios in complex systems, and the need to always keep scenarios current, relevant, and understandable.
Example Mapping
To help with writing user stories and trying to clarifying user acceptance criteria, teams can use the agile business analysis techniques such as example mapping to gain clarity around acceptance criteria by using multiple examples of specific cases to refine and establish clearer better-defined acceptance criteria for a certain story to show how the story works and offer better insight and provide more useful information for the user story.
Example mapping provides a shared understanding of the path forward and the need to add, remove, or adjust certain user acceptance criteria.
Example mapping involves gathering the team together who have different perspectives; establishing whether there is sufficient information in the user story to solve the problem – to help with this team members will ask the question – what happens if? Team members use sticky notes for each aspect of the implementation of the story:
- Yellow sticky notes – define the story itself and serve as the headline for the entire example map.
- Blue sticky notes – indicate specific business and other rules directly associated with the story.
- Green sticky notes – serve for defining the examples of the rules in the row above represented by the blue sticky notes.
- Red sticky notes – used for making note of the questions that arise during the discussion. These questions can be related to the examples, rules, or the definition of the story itself.
Impact Mapping
The technique of impact mapping uses visual maps to align deliverables and initiatives with the overall goals of the organisation. By focusing on the why? (value creation), rather than on what? (feature development) impact mapping allows stakeholders to be aligned with overall goals and value creation. The overall picture provided by the impact map also allows for the identification of specific details. This technique provides a connection between activities and organisational goals.
Impact mapping includes the following elements:
- Components – impact map has four key components: goal (why are we doing this?), actor (who can influence goals?), impact (how will actors influence goals?), and deliverable (what activities help actors complete goals?);
- Processes to create – creating impact maps includes four steps: gathering all stakeholders and team members for collaboration, finding space to create a visual map, identification of components to be presented, and keeping the map’s visibility for further revision.
The strengths of impact mapping include the focus on goals rather than features, waste reducing, transparency of project stages, short time required for creation, large context with little information, increased refinement, and decision making based on new information.
The limitations of this technique are that it requires face-to-face facilitation and the necessity of visual presentation and accessibility.
Job Stories
The job stories technique describes jobs that are required to be done by a stakeholder. These jobs can include backlog product items or requirements and focus on the stakeholder’s motivations and the context for those motivations. The Job Stories provide information that can influence the stakeholder’s decisions and their need for a certain solution. Also, they help stakeholders communicate, interact, and focus on customer’s needs.
Job stories include the following elements:
- Format – job stories are laid out in a specific format and can be written in the first or third person. An example of formatted job story syntax is the following:
When I want to so I can
- Situation – the situation is the first element of the job story syntax. Its role is to provide the existing context for the required job. The better and more extensive the context is described, the more options the delivery team has when deciding on a solution;
- Motivation – motivation is the second element of the job story syntax. It represents internal and external influences on the customer’s motivation;
- Expected Outcomes – expected outcomes are the third element of job story syntax. The desired outcome should reflect the underlying motivation.
The strengths of the job stories technique is that it removes persona biases, can be set up for cause and effect scenarios, emphasises motivations rather than implementation definitions, helps create user experience design, improves the team’s empathy to the stakeholder, focuses on the desired future state, and can be combined with user stories in the backlog.
The limitations include more verbal tendencies and occasional confusion between job stories and user stories.
Kano Analysis
The kano analysis identifies the features and qualities of a certain product that can bring an edge when competing on a market. It’s focused on the customer’s feelings on a product, which are used to better develop a product.
Through kano analysis, business analysts determine threshold or basic features that will satisfy customers, performance features (the more the better), the excitement features that the surprise the customers, and different features which are the ones that customers don’t want or need. The results are presented on an analysis graph measuring customer satisfaction.
Kano analysis includes the following elements:
- Threshold characteristics – necessary for developing a solution. They represent the minimum requirements, and their omission will cause the customer dissatisfaction;
- Performance characteristics – the presence of more performance characteristics in the completed solution increases customer satisfaction. They include features such as speed or ease of use;
- Excitement characteristics – these characteristics surpass the customer’s expectations and add features that the customer was not aware of;
- Indifferent characteristics – not needed by the customer and add no value to the solution. When recognised, these characteristics remain unused but are still represented on the kano analysis graph;
- Determine the category – the characteristic of a product are categorised based on the functional or dysfunctional form, i.e the presence or absence of the feature;
- Legend – abbreviations used in the graph. E for excitement, P for performance, T for threshold, I for Indifferent, and Q o R for questionable or reversed.
The strengths of kano analysis are the possibility for application for both consumer and non-consumer solutions and simplification of determining the feature priorities.
The limitations are that it only identifies customer satisfaction as a factor and the possibility of change of customer expectations over time.
Minimal Viable Product (MVP)
The minimal viable product (MVP) technique helps the organisation minimise risk and costs that come with developing the wrong product.
The initial stakeholders are presented with a minimal set of basic features sufficient for delivering value. The feedback for those initial features serves as a foundation for further development and adding new features. Minimal viable product technique usually involves three steps: determining the problem, identifying a minimal set of features for the test, and analysis of gathered feedback.
Minimal viable product technique includes the following elements:
- Target audience – identification of the likely users of the proposed solution;
- Goal to achieve or hypothesis to test – defining the goals or the hypothesis to be tested by the MVP technique;
- Mechanism to measure learning – objective measures used to evaluate the received feedback and learning;
- Defined requirements – minimal requirements needed for delivering the minimal viable product.
The strengths of the minimal viable product are that it’s less expensive than the development of robust features product, costs, and risk minimisation, preventing the development of unwanted products, and implementation of actual usage scenarios.
The limitations include the need for advanced market analysis, no precise formula for identification of the best features, testing of a hypothesis instead of creating an actual minimal product, and the lack of simple and clear solutions as an outcome.
Personas
The main purpose of the personas agile technique is the understanding of the stakeholder’s requirements and point of view. This is necessary to make sure that the solution is aligned with the needs of a stakeholder. Personas are actually fictionalised archetypes that help the analysts understand the user-solution interaction. The personas may be assigned a name, background, family. level of education, attitudes, and every other trait that may represent a real user.
The personas technique involves the following elements:
- Long and short template – two templates that provide a quick overview of key information on persona and a more extensive one providing detailed understanding, respectively;
- Persona name and image – realistic details to make persona more relatable;
- Traits and characteristics – unique characteristics mirroring the intended stakeholder;
- Motivations – underlying motivations for intended stakeholder’s interaction with the solution;
- Needs – specific needs assigned to the persona;
- Differentiators – specify what differentiates this persona and makes it unique.
The strengths of the personas approach are in facilitating a shared understanding of specific requirements, solutions aligned to the personal needs, creating personas out of an identified set of characteristics, and implementing individual values onto the solution.
The limitations include the risk of creating unrealistic and unrepresentative personas, the possibility of distancing the team from the real users, and the need for constant developments and updates.
Planning Workshops
Agile business analysis techniques such as planning workshops is used to define the value, functionality, or features of a solution that can be delivered over a certain time period. Often, the backlog refinements technique is used in the preparation stage of the planning workshops. The workshops are planned on two levels: current state before the iteration and the work to be done during iterations.
The agile technique of planning workshops includes the following elements:
- Estimated and ordered backlog – a key input for planning workshops. Includes estimations and ordered backlog sites;
- Team velocity – scheduling the realistic timeframe and amount of work through prior velocity;
- Iteration goal or feature set – overall goal used for the selection of features, met by implementing the backlog items;
- Backlog item selection – the process of selecting feature and non-feature backlog items in the order of priority;
- Task planning – smaller tasks derived from backlog items and assigned to the team members.
The strengths of planning workshops include frequent communication between stakeholders, the ability of product owners to guide the solution at every iteration, easier understanding and planning of the smaller scope iterations, ability to change the plans in advance as a response to received feedback, and visibility of solution thought the entire team.
The limitations are the necessity of gathering the entire team, time-sensitive understanding of the goal and backlog, and the possibility of a sub-optimal planning if the solution and backlog items are not clearly understood.
Portfolio Kanban
The portfolio kanban is a collection of frameworks that helps the implementation of agile principles and strategic initiatives through better visibility of the process, work-in-progress, criteria for decision making, and feedback loops. It’s used to manage the workflow through all of the stages of the project. Portfolio kanban includes all of the strategic initiatives that the department needs to execute to accomplish the desired goals.
Portfolio kanban includes the following elements:
- Kanban board – shows the steps taken to take initiative from idea to completion. It identifies in-progress initiatives, bottlenecks, priorities, and feedback loops. Every item on the board represents a portfolio initiative;
- Done criteria per column – explicit criteria that show that the item is complete and ready for the further move to a new column;
- Limit per column – limits based on the departmental capacity that are applied to each column. It helps move items through the portfolio in a reasonable time;
- Strategic business initiatives or portfolio items – every strategic initiative on the board with an assigned name, description, and metrics;
- Refinement meeting – regular meetings of all decision-makers and invested stakeholders where the decisions and changes are made based on received feedback;
- Metrics – initiatives are prioritised using impact metrics;
- Visual – the portfolio kanban board contains visual representations that ensure the accessibility and clear understanding of the included items.
The strengths of the portfolio kanban include replication at initiative and delivery horizons, optimised portfolio management, increased feedback loops, better visibility of ongoing work and potential bottleneck, and increased flow of the system due to the limiting work-in-progress.
The limitations are restricted usability when initiative moves through different columns, the need for sizing the initiatives, and the limitations when used on multiple systems.
Product Roadmap
Product roadmap is a strategic document that describes the progression and the applied measures such as Objective Key Results (OKRs) in reaching the desired goal. It provides insight into product development, aligns the work to the stakeholders’ needs, and helps determine the necessary budget. Its focus is on potential value rather than on milestones.
Product roadmap includes the following elements:
- Defined vision and strategy – the vision
defined by the product roadmap identifies what is needed for the solution to be delivered and how it will be accomplished; - Defined desired outcomes – clearly articulated desired outcomes enables the delivery team to develop a high-value solution;
- Product management team – led by the product owner or customer representative, this is a small team focused on maintaining the product road map;
- Themes – themes representing requirements, features, or stories;
- High-level requirements – items of high-level which are comprised of requirements and stories and contribute to the desired solutions.
The strengths of the product roadmap include visibility to all stakeholders, orientation to shared focus, diverse view of the solution direction, facilitating the discussion on options, and a variety of views for different audiences.
The limitations are ineffectiveness in fast-changing environments, possible misuse as milestones, and the time consumption if overly detailed.
Purpose Alignment Model
Used to evaluate ideas in the context of value, the purpose alignment model provides a two-dimensional assessment of features, processes, products, and capabilities. It’s used to determine the best possible actions for improvement of the said project items.
The first dimension of this agile technique rates features on the ability to stand out in the market. The second, on how critical it is for the functioning of the whole enterprise. By prioritising, the Purpose Alignment Model enables investing in the features that have the greatest potential to produce value to the organisation. Although it was developed for for-profit organisations, this technique is often used by governmental organisations and non-profits.
- Purpose alignment model includes the following elements:
- Differentiating quadrant – this quadrant of the purpose alignment model includes features, products, or services that are critical to the functioning and help differentiation in the market. They provide the company with the ability to stand out among competitors;
- Parity quadrant – this quadrant includes critical items that do not contribute do market differentiation. They include items such as HR, payroll, or accounting;
- Partner quadrant – this quadrant includes activities that are not critical, but provide value to the customers. They are not crucial for an organisation to survive. Sometimes, they are better left to the partner to perform;
- Who cares? quadrant – as its name suggests, this quadrant includes activities that are neither critical nor contribute to differentiation on the market. They are the first candidates to be removed and have the intended resources allocated to the more critical activities.
The strengths of the purpose alignment model are simplicity, ease of understanding, wide application, and fast analysis.
The limitations include the assumption of positive intent, the necessity of inclusion of the right stakeholders, and occasional tendency to overlook important features due to the simplicity of the technique.
Real Options
The real options agile technique provide the conditions where the decision can be made at precisely the right time. It determines when to make the decisions by reducing the total number of decisions to be made at a certain time and enabling stakeholders to delay decisions as long as possible. The real options follow three rules: options have value, options expire, and never commit early unless you know why.
The real options include the following elements:
- Options – available until a certain moment in time, options can be committed to or not. when decision makers commit to one option, others expire;
- Commitments – these may include using standard software language to build a product, turning up on time, or delivery of backlog items. Failure to meet commitments can put the whole process at risk;
- Options expiry – the determination of the time when the options expire is crucial for making timely decisions;
- Right/wrong/uncertain – the uncertainty of a rapidly changing context can make the same decision right or wrong depending on the time it was made. Through real options techniques, the analyst determines the right time to use the available information and make an informed decision. This allows them to gather information up until that time.
The strengths of the real options are simplified, optimised, and faster decision making process, and determination when to make a decision.
The limitations include occasional lack of intuitiveness and the complexity of the process.
Relative Estimation
Progressive estimation in an agile environment is aligned with iterations and provides predictions based on past experience, knowledge, size, and uncertainty regarding the completion of backlog items, among other things. The accuracy of the estimation depends on the time information is discovered and how close to delivery the estimation is provided.
Estimates are used for internal decision making and provide value to the stakeholders by evaluating the cost and effort, determining priorities, and committing to a schedule. The Relative Estimation involves process in which analyst define user needs and benefits by developing stories which are analysed and assigned a numeric value. Each story is assigned a relative number – a story point that is a reflection of the amount of effort needed to deliver that story.
Relative estimation involves the following approaches:
- Planning poker – used as an estimation technique for story points, planning poker involves a review of each backlog item and assigning a number to that story by each team member. If there is an alignment within one degree of numbers, one of them is chosen. In the case of wide variation, the discussion is continued to discover any new information or knowledge;
- Silent sizing – involves backlog items prepared on cards and placed on board by team members. The cards are lined up from the smallest to the largest and then grouped by size with each group assigned a number such as the fibonacci scale.
The strengths of the relative estimation agile technique are the simple methodology aligned with the agile environment and highly collaborative sizing approaches.
The limitations include questionable accuracy if the new stories differ from previous ones, the team-dependent accuracy of velocity, team-specific numbers leading to confusing comparisons between teams, and possible focus of outside stakeholders on the estimates instead of value delivered.
Retrospectives
Retrospectives support improvement by reflecting on the recent deliveries and establishing what was done well, what could be done better, and how to improve the whole process. This agile technique requires the participation of the entire team. The retrospective commonly consists of two parts: a reflection on past iteration and establishing the path forward. Normally, retrospectives are held at the end of each iteration so the learning can be quickly put to use in the next stage.
- Retrospectives include the following elements:
- Review previous action items – identification and review of the items in the previous retrospective;
- Preparation – preparing the ideas from the previous iteration for the retrospective analysis;
- Safety check – agreement on mutual trust within the team;
- Identify the items – identification of items to be discussed, commonly done by putting up successful items, failed activities, and things of interest on the board;
- Choosing future actions – deciding on the items to focus on in the future, including determination of the timeline and assigning responsibilities to the members of the team.
The strengths of the retrospectives technique include teamwork improvement, early detection of issues, team empowerment, ability to be done in entirety by the team itself.
The limitations are a possible false sense of trust within the team, value derivation only if learnings are used for further improvement, and leaving the issues to be dealt with in retrospective rather than handling them as they happen.
Reviews
The reviews technique is used for soliciting feedback by presenting a working solution. It’s led by team members and focuses only on completed solutions. For reviews to be successful they need to tie work with the organisational vision, goals, and objectives. Feedback receive this way is used to improve the solution so it can satisfy customers’ needs. It’s also used to determine the next steps in the project and prioritise certain features.
Reviews include the following elements:
- Solution being delivered – increments of the completed solutions provide tangible items for stakeholders to provide feedback on;
- Stakeholders – reviews involve key stakeholders with the best ability to provide feedback, team members who initiate the discussion and elicit feedback, and product owner/customer representative/product manager who lead the initiative and make decisions.
The strengths of the reviews technique include the informal manner of eliciting feedback, regularly conducted lightweight facilitation, use as a checkpoint for solution validation, face-to-face communication, early and continued stakeholder engagement.
The limitations include too varied feedback if the larger number of stakeholders is involved and sometimes lack of regard for organisational hierarchy.
Spikes
Spikes are used to gain the knowledge necessary for delivery when a backlog item or initiative cannot be estimated. They are time-boxed activities with clear objectives that include research, design, exploration. or investigation. They have a solely exploratory purpose and do not produce a product.
The spikes agile technique includes the following elements:
- Spike goal – spikes have clearly defined outcomes used to identify the completion of their purpose;
- Type of spike – spikes include three types: functional which analyses and breaks down the story, technical which determines the impact of the story, and exploratory which explores organisational risks or impacts.
The strengths of the Spikes agile technique includes focus for the team, permissions for value-driven research, and improved interaction between team members and shared knowledge.
The limitations are the restricted the clarity of outcome due to the too long time-box or too large items, incorrect use of the term to refer to follow-up, and decreased efficiency of the backlog refinement if the Spikes are used too frequently.
Storyboarding
In an agile environment, tasks, scenarios, and stories are usually described using storyboarding. This technique identifies how the stakeholders actually interact with the solution. It can be used simultaneously with other techniques, such as use cases, user stories, or prototyping. Together, they provide visual and textual detailing of user – solution interactions. Storyboarding is a convenient tool that can be used when the prototypes are unavailable, unnecessary, or too costly. Storyboards can be created in interaction with stakeholders and be either digital or physical products.
Storyboarding includes the following elements:
- Scenarios – for every possible user interaction with the solution, the business analysts develop a scenario containing the customer’s potential actions and the desired outcome. They also determine the likelihood of each scenario actually happening and the complexities involved;
- Illustrations – storyboards visually illustrate the solutions and customer interactions and usually feature a series of boxes for each step of the story;
- Textual explanation – each box is usually accompanied by a textual explanation providing further context;
- Create storyboard – creating a storyboard includes several steps: identifying the main scenarios, selecting the scenarios that require a storyboard, creating illustrations for selected scenarios, adding textual explanations, and validating the storyboard with stakeholders.
The strengths of the storyboarding include significantly reduced abstractness, quick and low-cost creation, and improved stakeholders’ engagement.
The limitations are that it feels and looks different than the final product, it’s easy to get stuck in the how instead of why, and the possibility of omission of some important rules or constraints.
Story Decomposition
Story decomposition provides a foundation for representing the requirements in greater detail and is structured in a way that starts with the broad context and breaks it down into smaller levels. The purpose of this technique is to develop the acceptance criteria for individual stories. The decomposition is applied to any story that is too large or complex to be easily understood as a whole. It’s usually undertaken progressively and each the completion for each story is incremental since they change over time.
Story decomposition includes the following elements:
- Solution goals – the highest levels of the requirement that all of the lower levels are assessed against;
- MMF/Component – minimal marketable features (MMF) represent the minimal functionality that makes the solution worth releasing;
- Story – user stories, cases, requirements, or job cases that will be implemented in the solution when it’s delivered;
- Acceptance criteria – conditions for the validation of the story. It provides validation for detailed requirements and can include lists of items, specifications, or user acceptance tests.
The strengths of the story decomposition are that it prevents getting to hang up on the story details, keeps focus on goals and objectives, helps planning, and provides insight into solution development.
The limitations include the temptation to treat it as a way of going back to detailed requirements upfront and often being based on process architecture instead on features of value to customers.
Story Elaboration
The Story elaboration represents the lowest level of the story decomposition and breaks down the story into detailed requirements and pieces of work. It’s used to define the acceptance criteria and detailed design for delivering the solution. It’s a continuous activity performed on a timely when-needed basis. It’s usually performed during each iteration in workshops with invested stakeholders. The outcome of story elaboration is an understanding among the stakeholders of what needs to be done to be able to consider state for this story “done”.
Story elaboration includes the following elements:
- Elicitation – obtaining necessary information from stakeholders to ensure that most recent and relevant feedback is included;
- Story decomposition – as described above;
- Acceptance criteria – clarification, adding, or removal of acceptance and evaluation criteria for the story;
- Additional optional elements – this technique may identify tasks needed for the next iteration to take place. These may include task definitions and breakdowns, examples of customer’s intent, low-fidelity models, scree or report mock-ups, and data tables for input/output.
The strengths of the story elaboration agile technique include the reduction of elicitation time, less documentation, avoiding work on features that will be changed when the implementation is ready, and focus on features of the highest priority.
The limitations are that the incomplete story elaboration may produce over or under-detailed story, difficulties identifying the proper timing, and challenges in elicitation.
User Story Mapping
The activities supporting the solution chan be visually represented by using the user story mapping. This technique allows for a better understanding of the product functionality, the flow of usage, and more precise prioritising of the delivery. Key aspects of the productions are represented on the horizontal dimension of the grid structure, while user story details and priorities are shown in the vertical dimension.
The user story map enables business analysts to visualise the outcomes, identify the dependencies that are the result of the flow through the user stories, and assess the risks.
User story mapping includes the following elements:
- Themes or activities – activities or themes that a customer will follow in a linear path are included in the top line of the story map. They present a broad view of all activities for all personas;
- Stories or features – individual stories are placed under the overarching themes and they present all of the known features for a theme;
- Ranked priority order – the stories, ranked by priority, are under each theme. This way, the features are separated between the releases. The ranked priority order indicates which stories appeal to the highest-ranked personas;
- Facilitation – story mapping does not require a dedicated facilitator, rather its self-facilitated. User story mapping often includes activities such as prioritising stories, identifying the ones that are missing, and selection of stories for elaboration and decomposition.
The strengths of the user story mapping include the ability to view the big picture instead of getting hung up on details, prioritisation based on the needs of the specific personas, and understanding the flow of data.
The limitations of this agile technique are issues with very large solutions and the lack of process-oriented contexts.
User Stories
The user stories present the needs and requirements of customers and convey them to the delivery team. They take the form of short concise statements that describe the features that bring the value. They provide better understanding and collaboration between the stakeholders. They can be written by business analysts, product owners, or customers. User stories ease the scoping and coordination of the user value for the delivery. The usual construct for creating these stories is the criteria marked by the INVEST acronym which stands for Independent, Negotiable, Valuable, Estimable, Sized Appropriately, and Testable.
User stories include the following elements:
- Card – the title of the user story in the form of the active-verb phrase which describes the activity that the user is expecting to carry out with the solution;
- Format – although there is no required format, the most common one has three components: persona (Who), action or feature (What), and the benefit of user received value (Why).
- Conversation – the purpose of the story is to provoke the conversation and communication between the stakeholders and team members;
- Confirmation – the need expressed in the user story is confirmed bu the business analyst using acceptance criteria which defines the story boundaries and verifies the solution;
- User story management – user stories impact several other techniques throughout the agile process: backlog refinement, product roadmap, story decomposition, story elaboration, and visioning.
The strengths of the user stories technique are rapid delivery due to its ties to small testable pieces of functionality, ease of understanding, ability to use various elicitation techniques. inciting further conversations, and facilitation of estimating, planning, and delivery through analysis models.
The limitations include inflated backlog if there are too many stories, the requirement for precise and relevant information, the necessity of constant refinement and prioritisation, and occasional loss of focus on the vision and value statement.
Value Modelling
Value modelling or the customer value model traces decisions to the stakeholders’ view of value in order to focus the development of a solution to delivering the value. It follows the simple structure of customer value = benefits – costs. Benefits referred here can be real or perceived, and the costs include direct and opportunity costs. Value modelling involves the following steps: stakeholder identification, determining stakeholders’ needs, and identification of the process that will satisfy those needs.
Value modelling includes the following elements:
- Customer – the focus is on delivery of value to the customer;
- Desired outcome or objective – value to be achieved by customer;
* Examples – the most common value modes are value proposition canvas, flow chart of customer value, means-value chart, and value model.
The strengths of value modelling are that it can be used at any agile horizon, process recording and traceability with minimal documents, and value-based decision making.
Value Stream Mapping
The complete and fact-based stream of activities for delivering value can be represented through value map steaming. It captures the snapshot of the value stream and is usually simple and drawn on the board. The most commonly used types of value stream mapping are current state value stream map and future state value stream map. This technique is particularly useful for reengineering the business and development processes.
Value map streaming includes the following elements:
- Prepare – this includes gathering of the cross-functional team involving subject matter experts and technical experts. The sessions are commonly facilitated by business analysts;
- Create current state – this includes naming the map, observing the value stream, drawing the value stream map, capturing the flow of vital information, building the model showing each step in the flow, identifying the waste steps that require elimination, and validating the value stream map;
- Analyse current state – this can be done using root cause analysis. The purpose is to identify value-adding steps and separate them from non-value ones;
- Create future state – this includes identifying the improvement areas and eliminating non-value steps, identifying improvement measures, capturing the future state values stream map, and using it as a target state for future improvement;
- Implement process improvement – this includes identifying the required material for improvement and implementing the improvement. The implementation turns the future state map into the current state value map which is used to kick off another improvement cycle.
The strengths of value map streaming are comprehensive flow diagram. creation of a blueprint for process improvement, improved identification and shared understanding of the waste and bottlenecks, and a common visual language as a tool for understanding between diverse stakeholders.
The limitations include somewhat complicated construction, daunting appearance, mapping paralysis, failure to produce results in knowledge-based work, and disruptive approach which may not work well with the current improvement efforts.
Visioning
Visioning provides guidance that helps determine the desired outcome and deliver value. It provides an understanding of the overall strategy and determines if the work is aligned with the organisational objectives. It helps keep all of the efforts on course towards the organisational vision.
Visioning includes the following elements:
- Vision statement – a visually represented statement that provides a clear understanding of the business values and the need for solutions;
- Vision exercise – the session facilitated by business analysts where the vision statement is determined in collaboration with stakeholders;
- Impact metrics – correlating metrics that determine if the organisation is on the course for achieving its vision.
The strengths of visioning include specified content of product or initiative, focus on the organisational value, and helping the organisation decide when to stop working on the initiative.
The limitations are the occasional failure to reference and use the otherwise valuable information in the latter stages of the process, no value if the information is not used for decision making, confirmation bias in becoming overly attached to the one solution, and dependence on imagination, trust, collaboration, and diversity.
Conclusion – Agile Business Analysis Techniques
A business analyst working in an agile context has to learn a number of agile business analysis techniques and apply agile business analysis best practices to add value to their projects and to enable business outcomes.
These agile business analysis techniques can be learnt over a period of time and demonstrated by working on projects that have an agile context to the ways of working.
Some agile business analysis techniques are more popular than others so start with those to get you started:
- Backlog Refinement
- Product Roadmap
- Relative Estimation
- User Story Mapping
- User Stories