Agile Business Analysis: Enabling Continuous Improvement of Requirements, Project Scope, and Agile Project Results

Agile Business Analysis: Enabling Continuous Improvement of Requirements, Project Scope, and Agile Project Results

by Kevin Aguanno, Ori Schibi


View All Available Formats & Editions
Choose Expedited Shipping at checkout for guaranteed delivery by Thursday, July 25


Agile Business Analysis discusses trends in the business analysis and agile environments, how these two areas align and promote each other, and identifies areas of responsibility and ownership for the business analyst (BA). Readers will learn ways BAs can provide support to agile projects through modeling techniques; documentation; communication, meetings and reporting; governance; building user stories, elaborating requirements, and facilitating the estimating process; ensuring effective application of lessons, improvements, and efficiencies; and much more. The book is designed for BAs of all levels, from all types of environments.

Product Details

ISBN-13: 9781604271485
Publisher: Ross, J. Publishing, Incorporated
Publication date: 11/13/2018
Edition description: None
Pages: 264
Sales rank: 592,920
Product dimensions: 6.00(w) x 9.00(h) x (d)

About the Author

Kevin Aguanno, PMP, PMI-ACP, CSM, has over 20 years of experience managing complex systems integration and software development projects. He is well known in the industry for his innova­tive approaches to solving common project management problems and focuses on two project management specialty areas: agile project management and troubled project recovery.

As a well-known keynote speaker, author, trainer, and coach in agile management meth­ods, Aguanno has taught thousands of people how to better manage high-change projects by using techniques from Scrum, Extreme Programming, Feature-Driven Development, and other agile methods. He is a frequent presenter at conferences and private corporate events where he delights audiences with practical advice peppered with fascinating stories from his own experiences in the trenches practicing agile project management. He is also founding Director and Vice President of the Project Management Association of Canada.

Ori Schibi, PMI-PBA, PMP, PMI-ACP, SMC, is President of PM Konnectors, an international consulting practice based in Toronto. With focus on project management, business analysis, and change management, his company provides a variety of services, including facilitation, workshops, training, and consulting, which deliver value to clients through a wide range of innovative business solutions. Many large to mid-sized organizations in diverse industries and levels of governments have benefited from PM Konnectors innovative services.

Mr. Schibi is a thought-leader and subject matter expert in business analysis and both traditional and agile project management. He is the author of Managing Stakeholder Expectations for Project Success, co-author of Effective PM and BA Role Collaboration, and a speaker and consultant with over 25 years of proven experience in driving operational and process improvements, software implementations, and complex programs to stabilize business, create growth and value, and lead sustainable change.

Read an Excerpt



Agile is not new, but its growth and increasing rate of adoption introduce new challenges (and opportunities) on an ongoing basis. Agile is also not the solution for all problems, but it is an approach, an umbrella, and a state of mind that, if done properly, can yield significant benefits for the performing organization. With that said, if agile is introduced the wrong way — in an unsuitable environment or under the wrong circumstances — it will cause more harm than good and there will always be someone who puts the blame on agile. While Chapter 2 of this book deals with challenges that emerge as part of adopting agile methods, this chapter introduces key agile concepts and examines the role of business analysis in delivering agile project success.


Agile is a pragmatic approach that recognizes that both the project team and the client do not know everything that has to be done up front, and that things will change along the way. Agile is an empirical approach — or, in other words, observation-based. It is open for changing needs and is evolutionary by nature, with multiple iterations (or sprints) — each producing a shippable product increment. The iterations are grouped into releases, where the customer actually receives, accepts, and, if needed, uses the released product increment. Agile addresses many of the challenges that were introduced by practices related to the waterfall approach, also known as a deterministic approach, where the team finalizes the requirements early on and then proceeds to build the agreed-upon product. Agile is made of the combination of two approaches: incremental (where product increments are released along the way) and iterative (where adaptation to change is continuous). Agile is not simply about breaking a large project into many small waterfall phases; there is more to it, thanks to the combination between the incremental and the iterative approaches.

It is not that agile is, plain and simple, better than waterfall. Although it addresses many bad practices that have been enabled by waterfall, there is still a place and time for a more deterministic approach. If a project has a set scope that is not about to change, and if the client does not need to benefit from early releases of the product by using it along the way, a waterfall approach may be suitable. Also, the fact that agile tries to fix some of the problems associated with waterfall does not mean that waterfall is at fault for project problems and is to blame for project failures. Waterfall simply enables some bad behaviors by allowing them to hide for too long before there are checks and balances to realize them. For example, because there are no interim releases and iterations along the way, the customer has the ability to see the product only at the very end — after testing has been completed — and only then can feedback be offered. It is possible that along the way the reports that provided the customer with updates were not portraying the actual picture, but the client had no chance to realize it because the reports were the only thing that the client had as proof of progress. This does not imply that the project team deliberately misled the client, but it is possible that information was communicated in a way that was misunderstood by the client. Good business analysis work and effective communication between the project team and the client can minimize the risk of such problems, but it provides no guarantee against such communication gaps.

Agile is an approach with several methodologies under Its umbrella. Some of these methodologies include Scrum, Feature Driven Development, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Disciplined Agile Development, and Lean Development. While deterministic approaches focus on the plan and provide less flexibility, they also provide less chance of meeting schedule and cost constraints, which might lead to time and cost pressures that in turn may lead to quality problems. Empirical approaches, on the other hand, are evolutionary, observation based, and focus on delivering value by locking time, cost, and quality goals and focusing on scope flexibility.

In the early days of agile, around 2001, when agile was named agile, there was little to no talk about business analysis, or business analysts (BAs) in agile environments — and it was for good reasons:

• The role of the BA was still undefined — it was prior to when the International Institute of Business Analysis was founded (in 2003) and prior to when the Project Management Institute expanded its focus to include business analysis.

• The main premises of agile — including its focus on handling change, being nimble, reducing waste, improving communication, and building teams that are more cohesive — are all about reducing the need for a BA to bridge and connect different stakeholders, groups, and teams. It was therefore expected that agile role definitions include only three roles: (1) the product owner; (2) the Scrum Master, coach, or a role that is somewhat equivalent to that of a project manager (PM); and (3) a team member (meaning all technical members of the team). While some interpretations call for the inclusion of a BA as part of the team, this was not the original intent. Another interpretation of agile concepts agrees that there is a need for business analysis skills, but this need has to be addressed by team members demonstrating business analysis skills, without calling for a dedicated or distinct role of a BA on the project.

This book covers the growing and increasingly recognized need to have the skills of the BA present on agile projects. At times, we will discuss the need for business analysis skills to be demonstrated by a BA, and at other times, ensure that team members can demonstrate these skills. One way or another, it is clear that these skills are necessary and are important for project success, but there is no one clear and correct way to apply them. This means that for some project environments, it would be sufficient to have team members demonstrating business analysis skills, while other project environments need a BA to champion these skills and ensure they are applied consistently and correctly. In retrospect, as agile is closing in on completing its second decade, it is safe to say that although agile attempts to produce benefits that, if performed properly, lead to a reduction, if not total elimination of the need of BAs, agile growth and the way it is applied bring back those needs and with them — at times — the need for a specific role of a BA within the team.

One of the reasons that has rejuvenated the focus on business analysis skills in agile environments is the rapid growth of agile, its scalability beyond technology projects, and the attempts to introduce agile concepts in organizations and environments that are not a natural fit for agile — including slower moving financial institutions and government agencies. With more projects attempting to apply agile concepts and more team members assigned to those projects, there is a need to refocus the efforts and to add checks and balances that reduce the chance that these projects will fail. When more people within the organization practice agile and when more agile projects are competing for scarce resources, it leads to what we identify as agile dilution, where there is a decline in teams' relevant agile skills and a reduction in the true agile experts in the organization to oversee, support, and lead the agile process.

Before proceeding to discuss the basic concepts of agile, it is important to make the record clear: agile is not about the following things:

• Not about working fast: but rather, building products in such a way that we can produce value earlier.

• Not about no planning: agile planning is critical for success and it is simply done differently and throughout the project, instead of a heavy focus on building a plan early on. Agile focuses on the act of planning, rather than on the creation of a plan.

• Not about no requirements: similar to the planning, an important part of agile is requirements. While they are referred to by a different name — user stories — there is a need to elicit and manage requirements. It is done in a different fashion than what takes place in waterfall environments, but properly managing requirements is a critical part of agile success. It is the level of detail around requirements that changes since the project starts with high-level requirements and then the team elaborates and seeks details on a timely basis — like a rolling wave, only for the requirements that are up next in the cycle. The team and stakeholders need to come to terms with the fact that ambiguity is welcomed until more information is needed. In a way, the requirements are partially trial and error because the requirements that are defined at the start of the project may need to change later on as more information is discovered during the detailed planning. Agile is no different than waterfall when it comes to ambiguity. In both types of approaches, there is ambiguity and there is no full set of detailed information up front — it is just that agile teams recognize the ambiguity and accept it, while in waterfall, there is an attempt to finalize requirements and their details up front. This latter effort costs a lot of time, effort, and money, only to go through the likely need to change these requirements later on — in a process that not only costs a lot, but also one that adds a lot of risk. The reference made here to trial and error does not refer to the project objectives or the project vision, but rather to the process of building stories and refining their details.

• Not about being careless: many organizations attempt to apply agile concepts into projects the wrong way, in the wrong context, and for the wrong reasons — leading to uncertainty, confusion, and wild-west behaviors where team members careen forward irresponsibly, attempting to do things too fast, moving forward without planning, making reckless decisions, and causing more harm than good.


Agile is a pragmatic approach that recognizes that there is a lot that the team and the customer do not know, a lot the team and customer learn along the way, and that things change without warning. Agile is a flexible approach that allows us to adapt and learn in real time as things happen, to respond to change, and to satisfy the customer as much as possible within the project constraints and realities. Agile projects start with a clear vision and product and are then broken into releases and iterations. The iterations should be of a consistent length (commonly, but not necessarily, between two and four weeks) and they are grouped together (any one or more iterations) into a release. Every iteration has a theme and goals and is made up of a slice of the project backlog (which is the total scope of the project — consisting of features, stories, and requirements). By the end of the iteration, the team needs to produce a working, production-quality product increment as if it was going to the customer. However, the product increment that is produced at the end of the iteration is for feedback purposes — the final product is actually delivered to the customer at the end of a release, with one or more iterations grouped together (and integrated through regression testing) — so this chunk of working product is a fully functional slice of the total product.

Known as iterative and incremental development, agile concepts help realize the following benefits:

• Adapt to changing needs, conditions, and environments in real time

• Produce benefits earlier through periodic releases of product increments

• Improve quality by giving the customer the chance to review progress periodically and improve based on actual performance and on the feedback provided — known as progressive requirement elaboration

• Reduce risk of building the wrong product and building the product with defects (the wrong way)

• Reduce scope efficiently through prioritization and reprioritization — agile enables the efficient reduction of scope by removing lower priority scope items in the later stages of the project once the majority of the value has already been delivered to the client

Additional characteristics of agile include accepting ambiguity in earlier stages until detail is needed, and ensuring that feedback is accepted as soon as possible so the team can properly act based on the feedback.

Lean Concepts, Wastes, and Principles

Additional agile concepts include the following:

Continuous improvement of processes (learning) — improving processes and practices on an ongoing basis: This concept is inspired from the term Kaizen in Japanese (Zen = good; Kai = change). The continuous improvement refers to small, incremental improvements to be learned, realized, and applied on an ongoing basis, unlike concepts such as Kaikaku (from Japanese — radical change) which refer to dramatic and quick improvements. Continuous improvement takes place in small doses over time, which improves the ability to apply them one by one, reduces resistance, and helps isolate the impacts of the individual improvements.

Customer focus: This is about producing and maximizing value for the customer.

Lean principles: The lean movement started in Japan in the mid-1950s in manufacturing (the automotive industry) with its main focus on loss reduction and sustainable production. Figure 1.1 lists the original seven wastes identified in the Toyota Production System by Shigeo Shingo. Agile is one of the most significant and successful attempts to translate lean benefits from manufacturing to software development and, subsequently, to other service and non-manufacturing projects. Lean development can be summarized by the following concepts that are very close in concept to lean manufacturing principles:

1. Eliminate waste: Activities that do not directly add value to the finished product are waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn, and crossing organizational boundaries. To reduce waste, the development teams need to self-organize in order to optimize themselves for the work they are trying to complete.

2. Build in quality: There is a need to design quality into the product, instead of relying on later inspection. But when this is not possible, there is a need to break the work into small and more manageable cycles that involve work-validate-fix-iterate. Inspecting after the fact and queuing up defects is reactive and ineffective.

3 Create knowledge and amplify learning: Promote strategies, such as iterative development, that help teams discover what stakeholders really need and act on knowledge as fast as possible. Leaning also involves frequent reflections and improvements.

4. Defer commitment (decide as late as possible): This is not a call for procrastination, but there is no need to start building a product by defining a complete specification. The design and architecture need to be flexible so they can change as needed. Deferring commitment to the last, most responsible moment allows the team and stakeholders to make the most informed decisions.

5. Deliver quickly (deliver as fast as possible): Quickly does not mean reckless; it is possible to deliver high-quality products quickly by identifying team capacity and limiting the work to this level. By becoming aware of its capacity (velocity), the team can establish a reliable and repeatable flow of work.

6. Respect people and empower the team: Sustainable advantage is gained from people who are engaged and thinking, and it is achieved by enabling and motivation, rather than controls and limitations.

7. See and optimize the whole: To achieve an effective solution, we must see the whole and the bigger picture, including understanding the high-level business processes that individual projects support across multiple systems and areas.

See Table 1.1 which illustrates the seven wastes of software development.

Combating Waste

To better understand agile principles and concepts, it is important to review the ways lean attempts to fight waste. For that, we need to check the underlying reasons behind the waste and think about ways to reduce or eliminate that waste. Although this book refers to the benefits of a BA, or the application of business analysis skills in any type of project environment, the wastes we cover here are the translations by the Poppendiecks of the manufacturing wastes that are identified by lean principles to software development wastes. The following are the seven wastes, along with the potential causes and solutions.


Excerpted from "Agile Business Analysis"
by .
Copyright © 2019 J. Ross Publishing.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Table of Contents

Foreword xiii

Introduction xv

Acknowledgments xxi

About the Authors xxiii

WAV xxv

Chapter 1 Introduction to Agile and Agile Processes 1

About Agile and Waterfall 1

Overview of Agile Concepts 5

Lean Concepts, Wastes, and Principles 6

Combating Waste 8

Back to Agile 19

Agile Principles 20

Tools and Techniques 21

The BA, Efficiencies, and an Eye for Waste 23

Recap: Agile Concepts 26

Endnotes 27

Chapter 2 Agile Challenges 29

Different Views of What Agile Is 31

Why Many Attempts to Go Agile Fail 32

Agile, Culture, and Organizational Change 34

A Review of the Agile Manifesto 35

Dealing with Organizational Change 41

Approach, Readiness, and Governance 43

Choosing the Right Approach 43

Agile Readiness 52

Agile Governance 57

Too Much Focus on the Process 62

Resource Management and the Matrix Organization 62

Cross-Project Coordination and Dependencies 63

Day-to-Day Challenges 66

The Diluting Effect 68

Bias 72

Scrum versus Agile 72

Recap 73

Endnotes 74

Chapter 3 Roles and Responsibilities 75

Agile Philosophy 75

Traditional Business Analysis Activities 76

Agile Business Analysis 77

Agile Challenges Where a BA Can Help 78

Getting the Development Team to Take Control of the Process 78

Waterfall Thinking 79

Micromanagement 80

The BA Role in Agile Projects 80

Being Ubiquitous: Creating Shared Understanding 81

What to Expect of the Agile BA 82

Focus 82

Innovation 83

Proactiveness and Initiative 83

Context 84

Critical thinking 85

A Balanced Approach 86

Storytelling 86

Leadership 86

Adaptability 87

Communication Skills 88

Agile BA Responsibilities and Activities 88

User Stories 88

Be There for the Team 89

Facilitation Skills 90

Help with Agile Ceremonies 90

Decisions/Decisions 91

Questions to Ask 91

Additional Considerations 92

Role Impact 92

Team Differences 93

Team Impact 93

Systems Analyst 94

End-User and Non-functional Requirements 94

The Product Owner 96

Testers 96

Technical Writers 97

Knowledge Management 97

Scrum Master, the PM, and the Team 98

Business Analysis and Project Activities 100

The Agile BA and Facilitated Workshops 100

The Agile BA During the Iteration 102

The Agile BA and Iterative Development 102

Kitchen Sink: More Areas of Value Creation 103

Recap 104

Endnotes 105

Chapter 4 Agile Requirements and User Stories 107

The Importance of Requirements 107

The Requirements Management Plan 110

Product versus Project Requirements 113

Overview of Agile Requirements 114

User Stories and Use Cases 115

Agile Requirements and Agile Principles 116

The Difference Between Agile and Traditional Requirements 118

Changes to Requirements 118

Whose Need Do We Address? 120

Developing User Stories and Requirements 121

We Need the BA 122

The BA and the Product Owner 123

Back to Developing Requirements 124

Writing User Stories 124

User Stories, Epics, and Themes 126

INVEST in a Good Story 128

Personas 130

Use Cases 133

Graphic/Diagram 133

Scenario 133

Actor 134

Business Analysis Skills 136

Transition Requirements 136

Visualizing User Stories and Agile Analysis Work Products 137

Flow Chart 137

Interface Analysis: Storyboarding, Mock-ups, Wireframes, and Prototyping 138

Context Diagrams 138

Data Flow Diagrams 139

Activity Diagrams 139

Class Diagrams 141

Entity/Relationship Diagrams (Data Diagrams) 141

Sequence Diagrams 141

Recap 142

Endnotes 142

Chapter 5 Agile Documentation 145

Documentation in Agile Projects 146

Agile Documents 146

Agile Reporting: Artifacts, Project Reports, and Information Radiators 152

Iteration Burndown 152

Velocity 153

Epic and Release Burndown Charts 153

Cumulative Flow Diagram (CFD) 154

Control Chart 156

Task Board or Kanban Chart 157

More Reporting 158

Back to Velocity 158

Recap 159

Endnotes 160

Chapter 6 The BA Role in Planning and Estimating 161

A New Role for the BA 161

Agile: Not Unleashing New Potential 164

Same BA Skills-Different Application 164

Application of Business Analysis Skills 165

Business Analysis Activities to Enhance the Focus of the Product Owner 167

Traditional Planning 168

Delays Are Nonlinear 170

Multitasking 170

Feature Prioritization 172

Uncertainty 172

Estimates versus Commitments 172

The BA in Traditional Projects 173

Agile Planning 174

Agile Approach to Planning 174

Three Levels of Planning 175

The BA's Role in Planning 180

Release Planning 180

The Prioritization Process 180

Estimating Complexity 183

Ideal Time 183

Story Points 184

Velocity 188

Forecasting Velocity 188

Iteration Planning 191

Recap 193

Chapter 7 Agile Events and Work Products 197

Product Backlog and Prioritization 197

Iteration Planning 199

The Importance of the Backlog 200

Project Backlog(s)? 201

End of Iteration Demos 203

Different Types of Demos 205

Demo Challenges and Issues 207

The Essence of the Demo 208

Feedback 208

Prioritization and Backlog Maintenance 210

Business Value and Prioritization 211

Reprioritization 214

Acceptance and Doneness 215

Handling Change 216

How Is Change Taking Place? 217

Retrospectives: Applying and Fine-Tuning Lessons 218

Recap 220

Chapter 8 Testing and Solution Evaluation 221

Agile Approach to Quality 222

Test-Driven Development (TDD) 222

The Growing and Extended Role of Testing in Agile Environments 223

Proactive Approach 224

Working Together 225

Early Involvement, Planning, and Estimating 226

Increasing Role of the Testers 226

Regression Testing 227

What Is Done? 228

Automated and Exploratory Testing 229

How to Deal with Defects 232

Are These Always Defects? 233

A Reminder: Testers Are Part of the Development Team 234

More about Agile Testing 235

Testing and the BA 236

Challenges with Agile Testing 237

Agile Testing Challenges 239

A Waterfall Contribution to Fixing Agile Testing Issues 242

Agile Testing Best Practices 243

Testers' Roles 244

Keys for Success 247

Back to the BA and the Testers 247

Agile Testing Strategy 248

Recap 249

Endnotes 249

Chapter 9 A Day in the Life of an Agile Business Analyst 251

Daily Patterns 252

Distinct Days 253

Differing Levels of Formality 254

Sample Case Scenario 254

The Last Day Template 255

Timing 257

The First Day Template 259

Timing 261

The Middle Day Template 263

Recap 266

Chapter 10 Moving Forward 269

The Challenges and the Business Analysis Skills 271

Agile-Specific Challenges 271

Other Challenges 272

The Business Analysis Advantage 274

Proxy Product Owner and What It Means 275

Agile and Social Implications 276

Dilution 276

Challengers 277

Forcing Agile 277

Defying the Laws of Physics 278

Decision Making and Generational Gaps 279

The Future 282

Automation 282

Distributed Teams 282

Organizational Agility 284

Interpersonal Skills 285

Social Trends 287

The Future and the BA 290

The Future Is Here 292

Processes and Exceptions 294

Disruptive Forces 295

The Right Way 296

The BA and DevOps 297

The BA and the Retrospective 298

The BA Is Not the Product Owner: The BA Is the BA 299

Endnotes 302

Index 303

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews