Agile and Business Analysis: Practical guidance for IT professionals

By Lynda Girvan and Debra Paul

Adopting an Agile approach can revolutionise business analysis working practices. Agile focuses on iterative development and incremental delivery of software solutions, enabling a clear focus on customer needs and early delivery of new or enhanced software products.

This revised edition reflects the latest Agile developments and provides a comprehensive introduction to Agile methods and techniques, explaining how they may be applied within the business analysis and holistic business change contexts.

Written by industry experts, this new edition is ideal for any business analysts who work in an Agile environment and wish to understand or extend their understanding of Agile practices. Recommended reading for BCS Professional Certificate in Agile Business Analysis.

• Language: English
• Publisher: BCS, The Chartered Institute for IT
• Release date: Mar 20, 2024
• ISBN: 9781780176192

Book preview

PREFACE

The first edition of this book was published in 2017 and considered business analysis from an Agile perspective and Agile from a business analysis perspective. We believed that a book was needed to explore these perspectives because of concerns about the recognition and application of business analysis within agile development environments. Since this time, some of our original concerns have proved valid as organisations have introduced agile approaches with varying degrees of success. Similarly, the recognition afforded to business analysis, and the corresponding level of business analyst involvement, has varied considerably.

The years since the first edition have brought greater experience of applying Agile in a wide range of contexts, including extending agile principles beyond software development to holistic business change. This was explored within the first edition but, given that holistic thinking is at the heart of the business analysis mindset, we have been mindful of this shift and keen to ensure we extend coverage of the business view of Agile. New ideas relating to key areas such as business agility and customer experience have become more prominent and prompted us to review and refresh the guidance we offer.

We continue to believe in the importance of tailoring the approach adopted to information systems work in the light of both the organisational context and the scope of the problem to be addressed. Over the last few years, the need to adapt to context and learn from experience has emerged as a key factor if the adoption of Agile is to result in beneficial outcomes. Given that Agile originated as a software development approach, adapting the agile principles and techniques to business improvement projects requires careful consideration and acknowledgement of the complexity inherent in business change. A prescriptive approach where methods are ‘followed’ without question is rarely successful, instead the focus must be on embracing flexibility, adaptability and customisation. Appreciating that one approach does not suit all (or any) contexts has ensured that relevant ways of working have been developed and applied. Inevitably, this has required problem-solving and thinking skills – significant items in the business analysis toolkit.

Our world view is always to consider the most appropriate way of achieving the desired outcomes that benefit the organisation. This is reflected throughout the book where we describe various approaches and techniques that enable business analysts, and any other IS professionals interested in this topic, to build a toolkit and apply it in an informed way.

Our aim in this new edition is to provide comprehensive and practical guidance that helps business analysts to gain insights into the application of Agile. We remain confident that business analysis aligned with an agile mindset has the potential to be transformative, improving not just the ways in which organisations operate but also helping organisations to encompass new value propositions and business models.

Lynda Girvan

Debra Paul

March 2024

1BUSINESS ANALYSIS IN AGILE ENVIRONMENTS

This chapter covers the following topics:

•the rationale for business analysis;

•business agility;

•the Agile business analyst;

•the growth mindset;

•the Business Analysis Service Framework;

•the Agile and Business Analysis book.

INTRODUCTION

All businesses have to be on constant alert for changes that may cause problems or offer opportunities. These changes may originate from industry factors such as competitor actions or may involve broader developments such as demographic or technology changes. In addition to these external forces, there can also be internal drivers for change such as business model revisions proposed by executive managers, service improvements identified by business architects or service designers, and updated working practices suggested by operational staff. While some drivers for change are highly visible, others can be subtle and easy to overlook so identifying change drivers may not be straightforward. While clarifying the source and rationale for change is necessary, the major challenge is ensuring the successful analysis, development and execution of the new ways of working.

Organisational change is often enabled by technological developments such as the introduction of new or enhanced software products, irrespective of the driver for change. Historically, changes to software have been viewed as the entire solution to a business problem or opportunity, and the broader context for using the new software has tended to be overlooked; the software product being perceived as offering sufficient new features to generate the efficiencies and improvements needed by the business. This approach began to change in the late 1980s when greater awareness emerged of the need to ensure that new software was accompanied by the relevant changes to other key areas such as processes and jobs.

Challenges have persisted, though, and the intervening decades have continued to be marked by highly publicised information systems (IS) project failures. As a result, there have been many initiatives to introduce methods and techniques intended to improve the quality of delivered change solutions including structured analysis methods, the Unified Modeling Language, systems thinking and business process re-engineering. There have also been attempts to move away from the more traditional, linear methods for software development and business change projects. Instead, there has been an increasing adoption of iterative development and incremental delivery approaches with a greater emphasis on meeting business change requirements when needed; these approaches align with, and have contributed to, the development of the agile philosophy.

The last few years have been marked by the widespread adoption of agile methods within the IS industry. This may be seen as a response to the traditional and structured software development methods, which have been challenged as not meeting the needs of today’s fast-moving business environments. While the original agile philosophy was focused upon the development of software products, it has become apparent that software development projects need to ensure that they are ‘business relevant’ if they are to support the working practices carried out by the business. Accordingly, the application of agile principles needs to move beyond software to encompass the entire business system if benefits are to be realised by organisations. Business analysis is a key factor in ensuring that this occurs.

Three particular issues have been identified:

1. The early rush to adopt agile methods and the resultant difficulties encountered when implementing Agile. It has often seemed as if many organisations and individuals wanted to jump on the Agile ‘bandwagon’ just to make sure that they were not left behind, but did this without giving due thought to the requirements that underlie the successful adoption of Agile.

2. The cynical response to Agile. This has been rooted in previous experiences with initiatives that had promised to avoid IS project failure – structured methods, object-orientation, formal governance, to name but a few. However, IS professionals need to reflect on the agile philosophy, tools and approaches in order to consider how they could improve and extend approaches to business change initiatives, including business analysis, to enable organisations to realise the intended benefits.

3. The software focus. The Agile Manifesto (explored in Chapter 2 ) is clear that the agile philosophy and principles are concerned with software development. However, this has been recognised for several decades as only one dimension for enabling business improvement.

Business analysis is concerned with resolving business problems and, typically, these need the people, organisation, process, information and technology aspects to be considered holistically. Although the original Agile Manifesto and philosophy focused on ‘working software’, business solutions must be viewed holistically and this is at the heart of business analysis. Failing to take a holistic view raises the risk of solving the manifest symptoms rather than the root causes of problems, and of investing in technology and applications that provide only partial solutions.

The valuable ideas that have been developed within the agile domain should be explored within the context of delivering business outcomes rather than software products. The role of the business analyst, with its focus on defining the problem to be solved and evaluating the options to do this, needs to be considered within this context. Accordingly, this book examines agile work practices through the business and business analysis lenses, discussing the use of agile methods and techniques within a business context and the role of the business analyst in conducting this work.

THE RATIONALE FOR BUSINESS ANALYSIS

Business analysis developed originally as a discipline responsible for analysing requirements, where the analysis activity was located firmly within the organisational context and analysts were familiar with the terminology, rules, standard practices and business processes applied within that context. Although systems analysis had been a key activity within the software development process for many years, problems had arisen because of an identified lack of understanding on the part of the systems analysts about the broader business context into which the IT system was to be deployed. There were criticisms that systems analysts focused solely on specifying system requirements and failed to consider what their organisation actually needed. For example, sometimes the organisation needed business process change in addition to enhanced software, but these changes were not within the remit of the systems analyst. The business analyst role emerged in response to these criticisms, to ensure that there was a focus on both the business and the software changes. Approaches such as requirements engineering were developed to ensure that both business and software requirements were identified, prioritised and delivered.

The increasing maturity of business analysis

The increasing maturity of business analysis over more than two decades gave rise to the creation of the Business Analysis Maturity Model in Figure 1.1. This model captures the trajectory of the development of the business analyst role as the scope of the role expanded and business analysts gained authority.

The three levels shown represent the different views of the business analyst role as follows:

•The initial focus on defining requirements as a basis for IT system development or enhancement.

•The extended focus on process improvement plus the attendant impacts on people and organisational structure.

•The movement into a role of trusted adviser, with a focus on asking ‘What problem are we trying to solve?’ and establishing the best means of addressing the problem.

Many change programmes and projects begin with an idea or initiative. This idea is formalised by the programme initiation, which includes a definition of the objectives, deliverables and timescale. However, sometimes, the idea is weak and may offer limited benefits, or may not improve the organisation at all. A typical example involves the purchase of a software package (or possibly an enterprise-wide suite of software packages) because it is felt that this will ensure benefit is delivered to the organisation. Without any analysis of the problem to be solved and the options available to the organisation, there is a high risk that the desired business outcomes will not be achieved and the project will fail. In the worst case, such an initiative could absorb a lot of (wasted) money and possibly cause damage to the organisation.

Figure 1.1 Business Analysis Maturity Model™

The increasing maturity of business analysis has coincided with the recognition that an initiating idea for change needs to be investigated to ensure that the actual problem is identified, understood and addressed, and the available options are defined and evaluated before actions are planned and executed. Business analysts have a toolkit of techniques and approaches that help them to analyse often vague and ambiguous business ideas based on statements such as, ‘we need to be more efficient’, ‘the processes are a bit cumbersome’, or ‘we have to enhance our capability’. Therefore, they are well placed to take on the work of uncovering the root causes of problems and clarifying the issues to be resolved. One of the key aspects of business analysis involves recognising that there are different perspectives on any business situation and without the development of a shared understanding and consensus view, it is going to be difficult to find a solution that will be acceptable to the key stakeholders. Business analysis also takes a holistic view, ensuring that all aspects of the business situation are considered during investigation and solution definition. The software product may be at the heart of the change solution, but without taking a holistic view of the people, their processes, work practices and information needs – and the organisational structure and culture – the solution is unlikely to realise the promised benefits.

BUSINESS AGILITY

The term ‘business agility’ seems to be ubiquitous, with organisations stating either that they have achieved this or are striving to do so. However, there are two questions to consider on this subject: first, ‘What is business agility?’, and second ‘How is it achieved?’

The essence of business agility

Business agility concerns the ability of an organisation to be responsive to forces in the external business environment and proposals initiated within the internal business environment. They can adapt when change is required. Systems thinking incorporates the concept of self-regulating business systems that can monitor the business environment through feedback loops and adapt to any changes encountered.

Organisations with business agility are able to act speedily, adopting new ideas and ways of working with minimal disruption. There are four components required to support such agility:

1. Leadership: leaders understand when change is needed, typically having the foresight to scan for environmental factors to which a response is needed and the motivation to ensure a response is made. Such leaders also embrace their change leadership, demonstrating their support and identifying where they should provide the required resources.

2. Capability: capabilities possessed by the organisation are understood, recorded and leveraged, with any gaps addressed when required.

3. Customer focus: there is clarity about the customers who purchase the organisation’s products and services, their value expectations and the value proposition the customers are offered. Employees strive to fulfil the value proposition.

4. Mindset: the employees predominantly hold a growth mindset and seek out opportunities to enhance the customer experience gained when engaging with the organisation. The structure is flat, the culture is open and adaptable, and employees are empowered and flexible.

Figure 1.2 Four dimensions of business agility

Underlying business agility is the need for the business system – or department, division or even entire organisation – to understand the rationale for its existence. Why does it do what it does? What are its core values? Simon Sinek (2011) highlighted the importance of understanding why an organisation exists before exploring the what and the how of the organisation’s operations. If the employees need to ask constantly how they should respond to situations or have to request approval for everyday decisions, there is limited potential for agility.

Achieving business agility

Sinek stated that organisations must possess a clear understanding of the rationale for the organisation’s existence and the corresponding values held by the organisation’s leadership. The rationale and values should underpin how the organisation operates, be reflected in the organisational culture, and should provide the employees with a basis for action and decision-making. Where business agility is the aim, empowerment is key and should be observable at all levels; the employees must be empowered to respond to customer needs and adapt to different circumstances.

Organisations striving for business agility do not have processes with a primary focus on ‘ticking the box’ – the work should have a real purpose and, fundamentally, that should be concerned with delivering the organisation’s products or services in line with the customers’ needs and expectations. This customer focus – and the ability of employees to make decisions to respond to customer requests – should be apparent to the customer. Some organisations proudly label themselves as ‘Agile’ or ‘operating with agility’ but a label is unhelpful if it is contradicted by the reality of the experience encountered. For example, many supermarket chains have introduced self-checkouts in recent years, which have the potential to offer customers a speedier means of paying for goods. However, the experience encountered can vary considerably between stores, with some of the checkouts providing a frustrating and time-consuming experience due to over-sensitive technology. In these cases, the systems seem to be set up to meet the needs of the organisation rather than the customers. As a result, at any moment, the system could lock up and demand the attendance of a store employee, resulting in a delay and frustration.

Some organisations focus on defined targets such as those encapsulated in their service level agreements (SLAs) and believe that ‘fulfilling the SLA’ is sufficient to ensure good customer service, even if this has just involved sending an email during the designated time period to confirm that the situation is still under investigation. Continually calling to say that no action has been taken is of no use to a customer, even if the internal communication target can be ticked as achieved.

Understanding and deploying the four components for business agility described above and recognising the nature of feedback and adaptable business systems, provides a basis for developing business agility. Business analysts who understand systems and service and apply the core agile values (Chapter 3) are able to support their organisations in the move towards agility.

THE AGILE BUSINESS ANALYST

There are two distinct aspects where the agile approach is relevant to business analysis:

1. The role of the business analyst in applying the agile philosophy and approaches within organisations, thereby enabling them to respond to change in an adaptive and timely way.

2. The role of the business analyst in supporting the use of agile techniques during business improvement and software development projects. This may involve the business analyst taking on other roles, such as the product owner or scrum master roles.

These aspects are considered in the following sections.

Business analysis enabling business agility

The underlying premise of several philosophies – Agile, Lean Thinking, Systems Thinking, Service Thinking to name a few – is that any business, system or process has an underlying rationale for its existence. In other words, it should be possible to state why the business, system or process exists. Understanding the underlying rationale helps to determine what needs to be in place to make the business work more effectively. Understanding and applying these philosophies is key to being an agile business analyst.

It has been said (by one of the authors) on numerous occasions that the role of the business analyst should be the most agile of the business improvement roles. This is because business analysis can apply different approaches and techniques as required and in a variety of contexts or situations:

•When challenging ideas, views and issues raised by business managers and staff in order to determine their relative importance and ascertain whether or not they align with the organisational strategy and tactics.

•When ensuring that different customer perspectives about a situation are understood and supporting the development of a shared perspective.

•When using techniques that allow the business stakeholders to provide relevant, timely information.

•When ensuring that options are always considered to determine where the best business outcomes can be achieved.

•When prioritising proposals and requirements at different levels of decomposition and focusing on the achievement of business goals.

•When aligning the different elements of the holistic view to ensure that change projects do not separate into individual silos.

Agile business analysts should support business agility both before the inception of a programme of change and during a change project, helping to ensure that change initiatives are focused on meeting the needs of the organisation and delivering the desired outcomes.

Business analysis on agile software projects

Several agile software development methods have emerged since the late 1980s, including Rapid Application Development, Dynamic Systems Development Method (DSDM), Extreme Programming, Scrum and Disciplined Agile. These methods are discussed in Chapter 4. One of the factors common to these methods is that they do not recognise the business analyst role explicitly. However, given that business analysis emerged to address the issues that had caused systems analysis to be criticised, primarily the communication gaps between technical and business staff, there remains a need for business analysts. In an agile environment, the role continues to have three primary aims:

1. To ensure effective communication between business stakeholders and the software developers.

2. To provide a holistic view that encompasses software development but also considers the other POPIT™ elements. ¹

3. To challenge ideas for business improvement and assess the impact of any proposed changes.

The agile principles, discussed in Chapter 2, highlight the importance of a face-to-face conversation between a developer and a business user when uncovering requirements. Highlighting the importance of a conversation to clarify requirements inevitably means that business analysis is needed, even if the work is done by someone with a different job title.

Individuals working within agile teams need to have relevant cross-discipline skills so that they can communicate and collaborate with the other members of the team, but they are not required to possess the skills to carry out their colleagues’ work. For example, software developers are not required to have extensive business analysis skills; business analysts are not required to be able to produce code. However, both roles should have sufficient awareness to collaborate successfully in developing the software product and holistic business solution.

Business analysts have extensive toolkits containing skills, techniques and approaches that they have learned and honed over several years, as is the case for other software development roles such as developers and testers. It may be useful for a developer to analyse the information being provided by the business user and consider the impact on the software product. However, in-depth analysis – such as determining business requirements or developing business models – requires more extensive business analysis skill so specialist business analysts are likely to be needed.

Agile Manifesto for business analysts

While the original Agile Manifesto stated which aspects of software development work had the greater priority, a manifesto for adopting Agile within a business analysis context requires a different perspective. While supporting software development is a key focus for business analysis, the software is rarely the entire solution to the business problem. Sometimes, the solution does not include technology change. Working software can enable the achievement of business benefits but, typically, other POPIT elements are needed to actually realise those benefits.

The original Agile Manifesto, with its focus on software, needs to be extended if it is to reflect the holistic nature of business change. There needs to be greater emphasis on improving the entire business solution and recognition that the realisation of business benefits results from business changes, not just software delivery. Therefore, the original Agile Manifesto is too limited for business analysts who need a modified manifesto that offers a broader view and has the potential to inspire an agile approach to business change.

A modified version of the Agile Manifesto, which is intended to work as an extension to the original manifesto, is shown in Figure 1.3 and reflects a business analysis perspective. This version embraces the Agile Manifesto and philosophy, but also encapsulates a world view that is relevant to business analysis and the broader business change context.

Figure 1.3 Agile Manifesto for business analysts

THE GROWTH MINDSET

In the bestselling book, Mindset (Dweck, 2017), Dr Carol S. Dweck describes her research into how individuals learn and improve their performance. She examined how individuals approach completing tasks, achieving goals and receiving feedback on results. Through this research, Dweck identified two contrasting mindsets – the fixed mindset and the growth mindset – and the issues that can result from a fixed mindset and the opportunities that are enabled by a growth mindset. Table 1.1 summarises the attributes attributed to each mindset.

Individual people do not possess either a growth or a fixed mindset as these are typically context or topic dependent. However, business analysts require a growth mindset when carrying out their work as it is essential for engaging with change and adapting to align with new information.

Table 1.1 The fixed and growth mindsets

Where a growth mindset exists within an organisation, openness and transparency prevail, helping to develop a culture of trust and encouraging experimentation and feedback. These qualities are at the heart of an agile approach so this is enabled by a growth mindset. Similarly, individual business analysts need to consider their mindset if they are working within an agile environment.

A growth mindset is essential for business analysts to be adaptable and collaborative when carrying out their business analysis work. A fixed mindset is likely to impede their ability to be an effective business analyst, as managing change and engaging with stakeholders is a key aspect of the role. The negative impact of a fixed mindset is particularly evident and unhelpful when working in an agile environment.

THE BUSINESS ANALYSIS SERVICE FRAMEWORK

Business analysis has developed over many years to become a broad discipline that encompasses several areas of activity. Research into the role of the business analyst identified that taking a service view and representing business analysis activities using a service framework offered the following benefits, by:

•offering business analysis practices a customisable foundation for defining the services and value propositions offered to their organisations;

•clarifying the role for both business analysts and their stakeholders;

•providing a basis for communication within the business analysis community and with other change disciplines;

•supporting business analysts with their career development and enabling job and career crafting.

The standard Business Analysis Service Framework (BASF) was developed to help business analysis practice leaders review their service offering and communicate this with their internal stakeholders. The BASF is shown in Figure 1.4.

The BASF may be used to define the extent of the business analysis landscape. The focus offered by the BASF is on the services delivered by business analysts and the value proposition offered to their organisation. This alternative view of business analysis contrasts with role-based definitions that often present an outline view that is ambiguous and risks misinterpretation. A service view of business analysis focuses on the outcomes to be achieved and considers the approaches and techniques needed to achieve this once the service, value proposition and outcomes have been agreed.

Figure 1.4 The Business Analysis Service Framework (Source: Paul (2018))

Business analysts need an extensive toolkit of skills and techniques if they are to deliver these services with proficiency. Agile approaches and techniques, and an awareness of the nature of iterative development and incremental delivery, are relevant additions to this toolkit, enabling business analysts to more effectively support the delivery of timely, effective change solutions. When analysing business situations, the agile toolkit offers a useful and relevant addition to the numerous business analysis skills and techniques. For example, MoSCoW prioritisation (see Chapter 8) may be used to prioritise business needs and software requirements.

THE AGILE AND BUSINESS ANALYSIS BOOK

This book was written with three aims in mind:

1. To help business analysts understand the principles and approaches that underlie agile ways of working and the business analyst role in software development projects.

2. To enable business analysts to apply the agile philosophy, principles and techniques during their business improvement work both on agile projects and in contexts where a hybrid approach that blends Agile with linear ways of working, is applicable.

3. To help anyone engaged in developing software without the participation of business analysts to understand the relevance and application of business analysis.

Accordingly, the principles, values and application of Agile are described within a business analysis context. The book covers a wide range of topics that are intended to support business analysts as they work on projects using Agile and provide services that enable their organisations to work with agility. The chapter breakdown is set out in Table 1.2.

Table 1.2 Structure of this book

Reviews for Agile and Business Analysis

[lkeighley-843201 · Rating: 5 out of 5 stars]

SummaryAgile is certainly a hot topic as more and more aspects of IT delivery (and Business Process) adopt the methodology. That adoption therefore drives employees and consultants to migrate their existing skills to that of the Agile approach, in line with the part they will play in that process. This book aims to take the existing Business Analyst through the conversion process as well as provide them with a reference guide for future use. Therefore, the book will provide a useful additional tool for that skill migration.ReviewThe forward to the book is written by Scott Ambler the author of Agile Modelling and the co-author of Disciplined Agile Delivery. This along with several other luminary recommendations of the book emphasises the regard the authors and content are held within the Agile community.The book is aimed at filling a perceived gap that exists in the Agile approach, of the need for Business Analysis principles to be available in an Agile manner. However, it does also stand back from this position to provide background to the principles and adoption of the Agile approach. Finally, it brings together the principles of Agile and Business Analysis to show how the two disciplines can operate together to enhance the delivery of IT applications and increase their benefit to business and/or organisation.The book contains sixteen Chapters, and each can be viewed as a separate entity as each has an Introduction and Conclusion sections. The Chapters take the reader through the background to Agile and its philosophy, the decisions and approaches that need to be adopted and finally to the aspects that need to be considered before that adoption commences and the implications on the Business Analyst role in that environment. The numbers of Chapters make a detailed review of these difficult, so the following is a selection of those I felt provided the most benefit, in terms of content, to a Business Analyst moving to Agile.Chapter 4 – Adopting an Agile Mindset – this provides information on how the core values within the Agile methodology can be adopted in Business Analysis. It is interesting to note that the Agile values were originally drafted for use in software development but that they can also be adopted in other ‘process’ or ‘change’ oriented situations and therefore fit well with the Business Analysis role and business change in general. There are 6 key agile values that relate to Business Analysis, Self Organising Team, Continuous Improvement, Iterative Development & Incremental Delivery, Planning for and Building in Change and Doing the Right Thing and the Thing Right. These are further expanded within the body of the chapter.Chapter 8 – Decomposing Goals – this highlights the need in the Agile approach to deliver business benefit, and therefore the derivation of business requirements, to utilising a goal-oriented approach to that gathering process. It is easy to think of goals as just requirements, but it is the subsequent decomposition of those goals in to smaller goals that can be delivered earlier, yet still relate back to the original, overriding goal. Care needs to be taken not to align these smaller goals with functional areas as this can lead to the original goal purpose being lost. This may be the most critical part of the Agile Approach and this chapter expands on these aspects.Chapter 9 – Prioritising the Work – this covers the need to prioritise the goals identified by the Chapter 8 process so that effective business change and delivery results. The Business Analyst will need to drive this to ensure that the most important and cost-effective goals are delivered first. This chapter provides a number of different prioritisation techniques that can be utilised, the most obvious being MoSCoW, Must Have, Should Have, Could Have and Want to Have but Won’t Have the Time.Chapter 12 – Modelling Stories and Scenarios – this covers the techniques used to model the functional requirements and their relationship to User Stories and Scenarios. It is easy to think that User Stories can be used to capture all the functional requirements but, as highlighted in this chapter, a one-size-fits-all approach should be avoided. Other techniques may be better placed to capture the detailed functionality and provide a more overall picture where high numbers of user stories are involved. This chapter provides some of those techniques as well as mechanisms for modelling a hierarchical structure of User Stories.Other chapters of similar importance are Chapter 7- Working with Stakeholders and Roles, Chapter 13 – Organising Tasks and Requirements, Chapter 14 – Estimating Agile Projects and Chapter 15 – Planning and Managing Iterations.The book provides a valuable reference for use in different projects, that due to their nature, may need different Agile approaches and therefore should be used to guide the Business Analyst when commencing a new Agile delivery.