As we move into the final two phases of using Design Thinking for good Business analysis, let’s do a quick recap of what’s been covered so far. In Phase 1 we discovered the current state through the Inspiration phase of Human Centred Design, using a range of planning techniques from BABOK® and design-based techniques to elicit, describe and capture the current state. This strong foundation of knowledge and understand lead into Phase 2 where we used Ideation to look at the ideal future state and started to elicit our requirements. Using techniques from Agile, Design Thinking and IIBA’s BABOK®, we have been able to create Sprints, wrapped our requirements into User Stories, and developed the product backlog that will take us through to the end of our journey. In the next two phases we will prototype, build, seek feedback, and complete our objective of delivering value through lean and quality requirements to address business needs.
Phase 3: Prototype and Build
With a full set of prioritised requirements organised in a Product Backlog, commence on finalising the future state process and building prototypes to support the process by transitioning from Ideation to Implementation. Work on the future state should involve the intended product or service being delivered and how the customer or user will experience it. How they will interact and use the service or product being created is critical for a successful delivery, and a number of techniques exist to help work this out.
Personas can plan a major role in reaching your destination. Understanding the different types of users, the demographics of your customer base and what their goals and needs are will be important. Using these Personas, development of Customer Journey Maps and Storyboards can provide additional tools in developing future state processes and prototypes. If you have multiple Personas, split off into small groups and brainstorm ideas for each specific persona then re-group to look for common themes. If your future state is developed enough at this stage, Rapid Prototyping may be used to understand the practical implications of your efforts and work can be undertaken to further refine and develop the product or service.
As your prototypes evolve and refined over multiple iterations, feedback must be consistently gathered to ensure the intended future state process is valid and the product or service remains desirable, feasible and viable. This can be done through the use of a Build-Measure-Learn loop within the Prototype and Build phase where Concept Models and Prototypes can be used with targeted user groups, observing how they interact with the solution, and adapting changes based on the observations. Your prototypes are the build, observation becomes the measure, and the outputs from observation become the learning that is then applied to making changes to your process and product or service. By repeating the cycle through a number of iterations until you are happy the process, product and/or service, you can be certain that valuable information is being assessed and implemented as needed to push you closer and closer to success.
Working for a business analysis consulting company I often come across clients who are looking for BAs with specific industry or solution knowledge. Whether it be Superannuation, Insurance, or software specific such as a certain type of CRM. Each time a filter is applied in the search for the ‘right’ BA, the search results decrease. This isn’t a bad thing, so long as the priority of those filters is applied effectively. If the first filter is the industry knowledge, followed by the business analysis skill set, are you really hiring a Business Analyst or a Subject Matter Expert?
The specific industry/solution knowledge may be simple to define. It might be as broad as finance knowledge, or as specific as banking experience focusing on term deposit management using a specific software type. This specificity may be well known by the business. Business Analysis is a defined skill set, though not always well understood by business. There are a number of standards, set by governing bodies, that define the knowledge and techniques required to be capable of delivering business analysis effectively. For a BA to be effective they need to have the right breadth and depth of BA capability suited to your project. The IIBA defines 6 key knowledge areas and a multitude of techniques that are applicable to each of them. Many, if not all of these knowledge areas are applied to each project. Secondly, underlying competencies, also IIBA defined: cultural fitment including teamwork, collaboration, transparency, integrity etc.
When businesses look to engage BAs, all too often they place priority of the industry/solution knowledge, over BA capability with the mind-set that it will take this “BA” less time to get up to speed with the business/solution and therefore be returning value sooner, with less disruption to the people around them. However, in reality unless you have hired someone with good BA capability you have just hired yourself another SME. And this person will apply only what they know to your business, rather than working with embedded SMEs to implement validated and verified solutions.
The Business Analyst and the Subject Matter Expert(s) have long had a collaborative and essential relationship. The SME is of course an expert in a particular area. They hold deep knowledge of the how’s and why’s of the part of the enterprise they work in. They learn this from completing their role day in and day out. The Business Analysts “enable an enterprise to articulate needs and the rationale for change, and design and describe solutions that can deliver value” (International Institute of Business Analysis 2015, Business Analysis Body of Knowledge v3). I have always believed the BA to be the least knowledgeable person in the room, but the one with the most capability of eliciting the required information from SMEs to deliver well thought out improvements aligned to all levels of the business (strategy to operations).
So, if an enterprise has placed industry knowledge ahead of BA capability, what’s the risk? Project success. If your “BA” does not have the capability to work across all levels of the business, collaborating with stakeholders to elicit the business needs, root causes of problems, alignment to business strategy, and be able to articulate this in a way that a developer can code a solution, then the purpose of your project is at risk. Project success is at risk.
So, the next time your enterprise is looking to recruit a BA, recruit a real Business Analyst, and let them use their skill set to work collaboratively with your SME(s).
Voltaire, a French writer, essayist and philosopher is well known for the saying that ‘[the] perfect is the enemy of [the] good’, meaning that, if you wait to be perfect or wait to achieve perfection then you’ll never get anything done, whilst achieving that which is good, or indeed, very good, is something of worth, especially in the face of nothing at all.
Some of us may reflect on that and ask, ‘well, doesn’t that view just allow us to willingly accept a deterioration in standards’, promoting a type of race to the bottom? To this I would say, if we had the luxury of having a bounty of time, finances, resources and energy then maybe striving for perfection would be both a valiant and noble goal, but our everyday reality dictates otherwise. As business analysts we operate in a world of projects governed by limitations on the resources that we have at our disposal. Aiming for what is good or very good in our world is what commercial entities require and expect of us.
THE PARADOX OF CHOICE
In the world that we business analysts reside, within the framework of Western industrialised societies, there is an official dogma that permeates our socio-economic fabric that supposes that if there is a desire to maximise the welfare of citizens, the way to do that is to maximise individual freedom. The extension from that being that the maximisation of freedom is derived through the maximisation of choices.
This central tenet guides all of our decision making and frames the psychology of various spheres or arenas of interaction, specifically in business. In our engagements, within the context of our projects, there is often the desire of the business to strive towards delivering solutions that can do it all, be everything for everyone, have every bell, whistle and toggle imaginable.
The interesting dichotomy between our social reality and the limitations imposed by business is that we, from the outset, seek to do it all, and as business analysts we can, and do, fall into the trap of acting as the agents of these desires. We effectively become the ‘waiters of the business’, running around, taking our orders of requirements, in the understanding that the freedom of the business to choose is paramount to delivering the desired outcome and additionally is paramount to being an effective business analyst. However, this is not the case.
Just as is the case in our everyday existence, when one is overwhelmed by options then we self-inflict our own analysis paralysis. As business analysts if we choose to act as the agents of ‘free choice’ then we too can instigate a type of analysis paralysis where both the decision making and psychology of allowing choices to be made within a set of overwhelming options produces a less satisfactory and less satisfying result, than if there were less options that were more pointed and guided to achieving the outcome of ‘the good or very good‘.
Not only can we inhibit the analytical process by vying to act as a facilitator for everything but we also foster the psychology of dissatisfaction. As business analysts and consultants we have our own duty of care to our stakeholders where we should aim to maximise their aggregated utility of satisfaction by assisting to find ‘best solution’ but not the perfect solution. The ‘best solution’ not being a sum of all requirements possible but rather being the best result within the constraints of the limitation of resources at our disposal. Inclusive within that aim is the management of the satisfaction of our stakeholders. From the perspective of the analyst this means not acting as the ‘requirements waiter‘ but rather being the gatekeep and rationalist driver of change. This means not allowing for a multitude of requirement alternatives to arrive at the bargaining table. We want our stakeholders to be empowered, to feel as though there choices are correct and for them not to be disappointed by having to make decisions that eventually would subtract from the final result or solution (inclusions), even if was a good one.
PARETO’S PRINCIPLE – THE 80/20 RULE
There are statistics that show that in software development 45% of the functions developed will never be utilised by users, 19% will be used rarely, 16% occasionally and only 20% will be used frequently or always. It’s an eye opening realisation when considering the resource effort utilised to research, develop and deploy 80% of the entire functionality. It also underlines how the paradox of choice underpins exactly what the principle states, the freedom of choice given to providing a solution undermines the development process of what is core to a solution.
The Pareto principle can be applied in almost any field of life, essentially promoting the thought that 20% of efforts will lend itself to finding 80% of the results. As business analysts this is a principle of significant importance as it can direct our focus to the areas of criticality when we are in our research gathering and requirements establishment mode.
Especially in environments that are Agile centric, the principle is one that a business analyst can use to drive both their focus and drive the entire team effort. Understanding that 20% of the given solution will contain 80% of the stakeholder and customer driven change, or that 20% of the user stories (functional work) probably contain 80% of the value, the business analyst can shape the work path to formulating an MVP (Minimum Viable Product) or MUST (Minimum Useable Subset). It’s a strategy that allows for the harnessing of limited/constrained resources and focusing it on the 20% of the functionality that is going to secure the greater part of the value for the stakeholder/customer.
It’s the utilisation of this strategy as a business analyst and consultant that allows to us to act as the fulcrum of change especially in environments where the freedom of choice inhibits the ability to quickly get to the core aspects of what the solution needs to achieve and how it needs to be developed.
It’s the art of understanding how to achieve the good, or the very good outcome that will prevent what may have been inevitable ‘analysis paralysis’ where the desire to have everything either achieves nothing or achieves a sub-standard result. If the aggregate utility of your stakeholder or customer is maximised by achieving a good or very good outcome as bound by the constraints of a business project, then it will beat a non-existent ‘perfect’ result every single time.
Our secret is not chaos or the latest fad but connecting business acumen with business analysis skills, techniques & competencies that fit the business need & its customers. Business strategy is about improving an organisation through requirements change. Business analysts know this well within our profession, using our own vocabulary for change, moving from “as is” to the “to be”.
Phase 2: Refine through Ideation
Now that we have defined our current state, it’s time to validate and refine it and start thinking about the future state. This is where we elicit and prioritise requirements, and finalise our scope. We want to be sure what we’re doing is desirable, viable and feasible, and that we can trace our requirements back to our business outcomes. There are several stages that can help us refine our work and prepare the Build and Prototype.
Stage 1: Validate the current state – Every Business Analyst should be familiar and comfortable with validation, it’s a core part of the job. We can use techniques such as Interviews or Workshops and our process models to take stakeholders through the current state and validate that our understanding is correct. There are a wide variety of visual representations and models that can be created to support this stage, the most important part is choosing the right one for your audience.
Stage 2: Requirements Elicitation – Using techniques like the 5 Why’s, User Stories, Epics, Finding Themes, Value Stream Mapping and ‘How Might We’ statements, we can work with our stakeholders to understand their needs and trace these requirements back to our business outcomes. It is important to make sure requirements have traceability to verified business outcomes, otherwise, how can we be sure they’re adding value to our final product? How your requirements are presented will be determined by the project and acceptable delivery methods, but the techniques you can use will vary. If you feel one method isn’t producing results, simply try another one or interchange multiple techniques.
Stage 3: Prioritise requirements – Working with your stakeholders, facilitate a workshop and get your audience to determine the priority of each requirement. By using MoSCoW, 100 point technique, Monopoly money technique or value-based prioritisation, your requirements should all be given an agreed upon priority level during the workshop. Keep in mind that requirement prioritisation should assess desirability, feasibility and viability in order to find that innovative sweet spot, along with the usual eye on your business outcomes, budget and scope. Once requirements have been prioritised, they may be grouped into Themes using affinity mapping, and further prioritised and organised into Sprints for a Product Backlog. With Themes and Sprints, development can be broken down into manageable chunks to achieve key deadlines or milestones more efficiently.
Stage 4: Finalise scope – Through the Discovery phase, work was performed to identify the scope of the project. Requirement elicitation usually captures some things that have been missed, and can also confirm previous in-scope items as no longer necessary. Review the Scope Models or Business Model Canvas that were previous created and validate them against the requirements and business outcomes with your stakeholders. You may even want to create a quick Storyboard to help visualise scope in another way, and work with the stakeholders to put firm boundaries around the scope of the project. This is the perfect time to use everything collected during Discover and Refine to ensure there is no scope creep during the development stages of the project.
As you work through each of these 4 stages, you’ll discover a pathway to your solution and future state is already starting to take shape. The work that has been done throughout Discover and Refine have laid the groundwork for the really creative stuff to begin. Stakeholders have been thoroughly and actively engaged throughout the process so far, and moving into the Build and Prototype phase, they’ll be able to get their hands dirty and drive the direction of the product or service to be offered.
Phase 3: Prototype and Build – Is coming soon!
The role of a Business Analyst is broad, but typically it comes down to understanding business needs, value & requirements and assisting business to make informed decisions. These needs are often muddied by a multitude of internal and external factors. In the end though, the goal is achieving organisational success. As all organisations exist to provide products and services to customers the best way to achieve success is to incorporate design thinking and human-centred design.
Design thinking is a creative approach to solution-based problem solving that puts people at the centre, enabling solutions that people truly want and need 1. While not a new concept, design thinking is making a comeback in the business world and producing a number of positive results. Together with User Experience (UX) and Customer Experience (CX), design thinking lays the groundwork for innovation, development of products and services, and ultimately helps you as a Business Analyst deliver better, stronger and more thorough business analysis.
The main aspect of design thinking is that of a user-centric experience; what is the user thinking and feeling, what is their experience. Business Analysts already consider these factors, but generally not at the level required to dig into design thinking. To dig deeper, the Business Analyst must step outside of their analytical mindset (without disregarding it completely) and let their creativity flow.
By understanding the customer journey and experience, we can get clarity on what the real needs are, and options to address them. Rather than interpreting and explaining what we think our stakeholders need, we can use design to clearly demonstrate what they need through the use of simple language that everyone can understand and use design artefacts to tell the story. When explaining complex issues to a business stakeholder, there’s an increased chance of confusion or misunderstanding if complex (or even mildly complex) approaches are used. Walking a stakeholder through a complex BPMN is a good example of this. But have you tried simplifying that process into a context diagram that uses simple language and a visual approach to explain the process? By changing the way we communicate complex systems or processes to stakeholders using design thinking, we can turn this interaction into a success. As a Business Analyst, clear communication is a core underlying competency. If we just end up confusing stakeholders, we’re not doing our job.
We have broken our analysis technique into four phases that closely align to design thinking, aligning these to the three phases of human-centred design, and will use this series to explain how the various tools and methods available in the BABOK® can help make your business analysis effort much more effective, adaptive and responsive to a rapidly changing business environment.
Phase 1: Discover – We will look at the Inspiration phase of human-centred design and various BABOK® techniques to understand the current state and help develop a more effective discovery stage. How can we use design thinking to understand the current state as fast as possible without adding risk?
Phase 2: Refine – Now that you have built a solid foundation and your as-is analysis is complete, how do we transition from Inspiration to Ideation? How we validate the current state with the business, turn our value streams into epics, iterate our work, and define requirements?
Phase 3: Prototype and Build – At this point we start to look at the future state, what will the to-be processes be, how we move through the Ideation phase. Prototyping of solutions, iterative building, role-playing and storytelling all play a part here.
Phase 4: Feedback – The Implementation phase of human-centred design, this is where a tangible product or service takes shape. This phase will often loop iteratively with Build & Prototype, and even back to Refine on occasion. Here we will be looking at our requirements and user stories to make sure they have been met and fine-tuning our processes to support the finished build.
My view of design thinking is an iterative process to Discover, Refine, Build & Prototype, and Feedback which helps deliver the business need, value and requirements.
Phase 1: Discover the current state through Inspiration
When we think of discovery, we understand there is a level of uncertainty or a realm of unknowns that we need to identify in order to deliver a successful project. Unknowns lead to potential roadblocks later with scope creep, failing to properly identify or understand the problem/opportunity, and ensuring a solution is fit for purpose. Through the use of a few techniques, we can better define the problem up front and ensure we have clear scope for the project. To do this, there are three key stages a Business Analyst can use to do this well.
Stage 1: Planning – The BABOK® has a chapter called Business Analysis Planning and Monitoring, so for the sake of brevity I won’t go into too much detail here. In this stage, the Business Analyst should be laying the foundations for success, by planning the core activities, tasks and deliverables needed, usually in alignment to a schedule. In the planning stage, the BA should also be performing initial stakeholder analysis activities such as Mind Mapping or creating Stakeholder Lists, Maps or Personas to understand which stakeholders are relevant to the outcome, what the BA requires from them, and the best way to engage with each stakeholder. An early activity to complete with stakeholders is to identify and prioritise the expected business outcomes for the project. Use Interviews, Mind Mapping, Value Stream Mapping or Workshops to identify the key business outcomes, and Grouping (high, medium, low) or negotiation to establish the priorities of the business outcomes. These outcomes will play a crucial role later in the project for traceability.
Stage 2: Current state analysis – A key part of the discovery process is eliciting the current state. What product or services are being delivered to customers. This is where most of the work should occur in this phase, and relies on a wide range of techniques. The purpose of this analysis is to understand what the intent of the project is, define scope for the project, understand the current processes, and validate everything with the stakeholders. Current state analysis should always be done, from a new start-up to an existing business or service, there are always unknowns that need to be discovered. Some of the activities you may perform at this stage include:
- Develop a problem or opportunity statement – Work with the key stakeholders to define and establish the problem in clear and agreed upon terms. This could include a context diagram of the problem, developed in a workshop on a whiteboard, or a mission/vision statement that provides verbal context to why the project is happening. BABOK® “Business needs are the problems and opportunities of strategic importance faced by the enterprise.
- Problem statements are about resolving an issue that exists, opportunity statements are about taking advantage of identified opportunities to enhance the organisation. A ‘How Might We’ statement can be used to help develop the problem or opportunity statement, and should ultimately describe an opportunity. Other techniques available to establish a statement could include Brainstorming and the 5 Why’s.
- Define a clear scope statement – As part of the same initiation workshop, the Business Analyst should work with the stakeholders to establish clear scope for the project. Use Post-It notes to assist in identifying assumptions, constraints, and dependencies. Post-It’s can be placed into labelled buckets for anonymity or displayed on a board for all to see. BA-led discussion should follow to assist in prioritising and establishing the final agreed upon scope. Scope Modelling or a Business Model Canvas can be created to visually capture and validate scope statements.
- Prepare for and elicit the current state – There is always a current state, even if the business or service is new & is in start-up mode. What is happening in the market, who are the competitors and what are they doing? These are all valid current state questions. A successful Business Analyst will have a clear plan and toolkit ready for elicitation. Mind Mapping, User Stories, the use of Personas, Journey Mapping, Value Stream Mapping, and Collaborative Gaming are just some of the techniques available to help elicit the current state from your audience. The stakeholders, problem or opportunity and scope have been clearly identified in previous activities, now it’s time to conduct your workshops, interviews and other techniques to elicit the current state.
Stage 3: Document the current state – Ensure the processes match products and service offerings. The use of context models and diagrams, as well as process modelling will help to validate the current state with key stakeholders. The format and structure of the outputs should be agreed with the stakeholders in the planning stage, and distributed for feedback.
By planning, eliciting and specifying a current state, Business Analysts can ensure they are well positioned to capture requirements and develop a future state that is desirable, viable, and feasible for the organisation. Finding this balance is where innovation generally occurs, which is something we should strive to achieve in everything we do.
Phase 2: Refine through Ideation – Is coming soon!
Product Owners are supposed to be the informed leader who is able to provide direction to the development team on the expectations of the product. As more organisations look to adopt an adaptive/agile approach to project delivery, one of the big issues faced lies with the Product Owner. Unfortunately, in increasingly common cases, the criteria for a suitable Product Owner seems to be resource availability, followed by resource availability. This places more responsibility on the development team, especially the Business Analyst, to work with the Product Owner to ensure what is about to be built, is of value.
Product owners can be assisted by a number of analytical techniques. The one which will be explored in this blog is Impact Mapping.
Impact Mapping is a technique used to drive value and prevent over-engineered solutions. It places the overall Goal of the initiative as the main focal point (why are we doing this?), and then delves into the people we are doing this for, who can help it be done, or who can stand in its way (Actors), how the actors can help, change behaviours to help, or impede the goal being achieved (Impact), and plausible deliverables that can be created to address that impact (Deliverables).
This creates greater insight for the Product Owner and delivery team, which assists in maintaining focus during story definition, decomposition, prioritization, and delivery. Impact Mapping works both ways. Like forwards and backwards traceability, Impact Mapping can be used to maintain control of scope (forwards), and as also be used to question the logic of identified deliverables against the overall goal (backwards).
There are multiple points in an initiative that you can use Impact Mapping. And the results can be used throughout. At the start of project definition Impact Mapping can be used to identify features that would be suitable to achieving the project goal. From here you can move towards story definition and mapping to identify dependencies and conduct release planning. You can use Impact Mapping throughout the initiative as a way of checking when the original goal has been achieved. This is the part of Impact Mapping that mitigates against over-engineered solutions. Additionally throughout iterations the results of Impact Mapping can be used to maintain focus for delivery teams – why are we doing this again, who are we doing this for, what impact is this feature supposed to have – bingo!
Like all business analysis activities good preparation aids good performance. So make sure that you choose a suitable space for collaboration. Have all the necessary workshop aids (whiteboard, butchers paper, or better yet, a device to model and present). Start the session by setting the business goal (be SMART). Then work through the process by identifying the people, Actors, who we are doing this for, the expected Impacts the initiative will have, and then of course, identify the Deliverables. This works like a brainstorming session. You can do the backwards traceability at the end to de-scope (or deprioritize) deliverables that don’t directly align to the overall goal. Remember to document your assumptions. They will be key when questioning the logic.
Business Analysts have always had a broad role, and we remain cross-functional. Part of adaptive/agile is about measuring success through the delivery of valuable software. Without clearly distinguishing this value early, any project is destined to fail (the speed of failure becomes the variable). Impact Mapping is a simple tool to help Product Owners and Development Teams set off in the right direction and maintain focus throughout.
To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn
A modern and innovative breed of systems delivery has gained significant momentum over the past one and a half decades, one that emphasises the ability to adapt to changing requirements, engage customer collaboration, and deliver a working software early and often. Agile was slow to start but quick to dominate, with most growth occurring in just the past five years.1 Evidently, Agile has now become the norm.
As organisations need to continually adjust to rapid changes from disruption and more customer-centric designs, even the organisations’ program governance and project management offices (PMOs) have also embraced the much-needed agility. The three planning horizons—Strategy, Initiative and Delivery—are key to driving Agile transformation across the organisation, and offer an apt framework for the shift in focus that occurs when moving between understanding the long-term strategic needs of the business and the immediate needs of a customer. 2
Strategy Horizon 3
According to former General Electric CEO Jack Welch, “an organisation’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage.” The goal of the Agile PMO working at the strategy horizon is to enable organisations to rapidly and effectively steer their products, services and initiatives without losing sight of business value, and to quickly redeploy available resources where they are needed the most.
The strategy horizon equips the Agile PMO with the ability to respond to rapid changes to customer expectations, the outside environment and the organisation. Further changes may emerge from analysing threats and opportunities, and learning from the frontline where the customers and various user personas are. Outcomes of the agile business analysis may result in starting a new initiative, or changing the resourcing, scope or success criteria of existing initiatives, or even cancelling an existing initiative that has become less relevant or less likely to succeed.
Initiative Horizon 4
The initiative horizon begins with the Agile PMO defining the needs to be satisfied, and concludes with identifying the aspects or components of the solution (aka product features) that will satisfy these needs.
As Peter Drucker, the founder of modern management, states, “There is nothing so useless as doing efficiently that which should not be done at all,” and the initiative horizon would attest to this fact. In this horizon, the Agile PMO gauges whether a solution is worth considering for implementation. The outcome of the agile business analysis is the collection of programs, projects and portfolio that is delivering the overarching strategy. When assessing solution options, various aspects are considered: (1) the shared understanding of the need to satisfy, (2) any assumptions made around the viability of a solution, (3) risks introduced from satisfying the need and the cost of mitigation, and (4) the constraints that may make some solution options nonviable.
Delivery Horizon 5
The outcomes of the agile business analysis from the strategy and initiative horizons cascade further down to the delivery horizon. In a nutshell, this horizon revolves around the Agile PMO confirming a shared understanding of the need, and whether the need has evolved or is no longer valid.
The Agile PMO working at the delivery horizon needs to ensure that requirements are mapped correctly to the business goals by identifying and prioritising a backlog of actions that will meet the need. The backlog items are then refined into implementable units of business value and elaborated into detail on a just-in-time basis.
Emphasis is on “just enough details” to avoid rework or waste from decomposing features into user stories too early, of which may change as new information comes to light. This backlog is continually re-prioritised, with items being flexibly removed and added at backlog refinement meetings or informally as needed. It is also imperative to establish a means of assessing outcomes, through immediate feedback from testing and customer evaluation, just to name a few.
However, note that the ‘buck doesn’t stop here’ in the delivery horizon. Sir Winston Churchill once said, “however beautiful the strategy, you should occasionally look at the results.” Learning from implemented stories is elevated back to its precursors, the initiative and strategy horizons, through open channels of regular and timely feedback.
One key aspect of a successful application of Agile PMO is that decisions are not made on stale data. In addition, unlike the strategy and initiative horizons that may have a medium-term outlook and a high-level view, the delivery horizon focuses on the specific aspects of the solution that are currently being developed or were delivered in the most recent increment.
Key Takeaway 6
Each horizon uses different perspectives, timing and levels of detail. The specific time spans for each horizon differ from organisation to organisation, but the concept of planning at multiple time horizons and different levels of granularity is central to Agile PMO business analysis.
1 Hewlett Packard Enterprise, Agile is the new normal (March 2017)
2, 3, 4, 5, 6 IIBA® and Agile Alliance Agile extension v2
Business analysis is not for the faint hearted. At the heart of business analysis lie eliciting, analysing, validating and managing needs, value and requirements, no matter what approach and method is used. Requirements (written as user stories or otherwise), should align to the needs of the business whereas design definition represents the solution put in place to address those needs.
A smart and diligent sponsor and project manager will never risk the possibility of misalignment between the solution design and the requirements, value and needs. A slot is made in the project plan to call upon the expert in this space, a good business analyst who will take due care to ensure that the design definition aptly meets the stated requirements and highlight areas of misalignment. To do so, the business analyst leverages a distinct tool in the toolkit, known as – ‘Requirements traceability’. Equipped with this tool, along with an analytical mind, the business analyst should continually review the design to ensure that the solution aligns with the requirements.
Time and effort invested by the Business Analyst in tracing the requirements against elements of the solution design help to confirm areas of alignment and flag areas of misalignment between the two. Managing traceability of needs, value and requirements against design helps identify a requirement or a set of requirements that is not met by the solution or a functionality. On the other hand, it also helps to identify areas within the solution or those functionalities that do not support any requirement.
Layering the solution design map on top of the traceability helps the Business Analyst to provide a managerial summary along with a stratified view that suits a broad spectrum of audience. In simple terms, while requirements traceability provides the fact, a solution design compliance map helps to publish those facts at various dimensions and helps decision makers to pull the right levers to fill the gaps. While the requirements traceability highlights the trace between each functional component of the solution design, and requirements, the solution design map summarises the extent to which the solution design meets the stated requirements.
A solution design map aids smarter impact analysis and informed decision making. It is good to provide a hawk-eye’s view and then dive into details. To start with, provide a view of the overall compliance of the solution design against the stated requirements. This will help identify the number of requirements that have been either fully met, or partially met or not met at all or those that have been removed from scope. The following pie-chart is a good example of that:
Requirements should be prioritised based on their value to the business. It is important for decision makers to understand the extent of solution design compliance against the most critical requirements and that against the rest of the requirements. The following pie-chart provides an example of that:
The requirements can also be attributed against the functional areas of the business to give an indication on which areas the solution has initially met the requirements against best. This gives a greater insight into risk identification and risk management.
Leveraging tools such as requirements traceability and solution design compliance maps help the Business Analyst perform a thorough review of the final design specifications against the requirements and presents the findings at a level that help influence the decision makers to make changes and ensure an optimum alignment between the two. Traceability, therefore, is the key to managing needs, value, requirements, and the solution.
User Stories and User Story Mapping are must have techniques of a business analyst. You can do business analysis without Scrum, but you can’t do good Scrum without Business Analysis. Story mapping enables clarity of user stories.
“Story mapping is the process of arranging user stories into a useful model to help understand the functionality of the system” http://jpattonassociates.com/the-new-backlog/. This technique allows for the planning and prioritising of requirements in order of importance and value. Story mapping orders user stories along two independent dimensions. The horizontal axis depicting the user activities in order of priority or the sequence of process activities and the vertical axis depicting the release or project milestones https://www.agilealliance.org/glossary/storymap/.
Once used, story mapping can enable the project team to dice stories (often at Epic level) horizontally into the main functionality. This horizontal view is important as it visually represents the value stream of the designed solution. This analysis allows the project team to understand the dependencies and highlights gaps for how the created user story functionality will work. This end to end perspective can be enhanced by understanding the customer journey of a person using the solution.
Having knowledge of the process enables the identification of stakeholders to be brought into the picture. The additional identified stakeholders help validate whether user stories are accurate and allows the project team to introduce change management activities early. One change management strategy which user story mapping encourages is to facilitate stakeholder buy in. This is vital and benefits the project team as these stakeholders can help develop additional user stories that the project team potentially have missed, elicit business impacts and helps validate design and prioritisation discussions.
The vertical axis is important as it represents the project teams user story release plans. Project team discussions will be centred on which user stories are high value and easy to develop. Complex user stories could be left to later releases with the focus of the project team having to create a minimum viable product for the customer. Sprint reviews can help fine tune the product and allow the project team to regularly assess user story release patterns. The vertical positioning of user stories enables the project team to discuss whether user stories can be prioritised in terms of need, value and complexity.
User stories capture requirements and the use of User Story Mapping, although simple, can be used to model a meaningful sequence of user activities, perpendicularly across a prioritised ranking of user stories. The benefit of which encourages richer discussion in planning and prioritising user stories, further engages stakeholder participation, is a mechanism to help understand business impacts and can allow a team to visually see how user stories affect the customer journey.