The document is a presentation about the role of a business analyst on an agile project. It begins with an introduction of the presenter and their background and experience. The agenda then outlines topics to be covered, including a brief overview of agile, the role of a business analyst on traditional and agile projects, why business analysts are important, and a question and answer session. It discusses challenges with traditional software development and how agile aims to address these.

1. The Agile BA
Understanding the BA Role
on an Agile Project
Presented by
Bill Gaiennie, Davisbase Consulting

2. Introduction and Agenda

3. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda

4. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
• A Brief Overview of Agile

5. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
• A Brief Overview of Agile
• The Role of a Business Analyst on a Project

6. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
• A Brief Overview of Agile
• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project

7. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
• A Brief Overview of Agile
• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project
• Why Business Analysts Are Vital to Successful Projects

8. Introduction and Agenda
• Bill Gaiennie, DavisBase Consulting
– 15 years in software development
– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
• A Brief Overview of Agile
• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project
• Why Business Analysts Are Vital to Successful Projects
• Wrap-up and Q&A

9. Building a Tire Swing

10. Building a Tire Swing
How the customer described
what they wanted...

11. Building a Tire Swing

12. Building a Tire Swing

13. Building a Tire Swing
How the project manager
understood it...

14. Building a Tire Swing

15. Building a Tire Swing

16. Building a Tire Swing
How the architect
designed it...

17. Building a Tire Swing

18. Building a Tire Swing

19. Building a Tire Swing
How the programmer
wrote it...

20. Building a Tire Swing

21. Building a Tire Swing

22. Building a Tire Swing
How the business consultant
described it...

23. Building a Tire Swing

24. Building a Tire Swing

25. Building a Tire Swing
How the the project
was documented...

26. Building a Tire Swing

27. Building a Tire Swing

28. Building a Tire Swing
What operations
installed...

29. Building a Tire Swing

30. Building a Tire Swing

31. Building a Tire Swing
How the customer
was billed...

32. Building a Tire Swing

33. Building a Tire Swing

34. Building a Tire Swing
How it was
supported...

35. Building a Tire Swing

36. Building a Tire Swing

37. Building a Tire Swing
What the customer
really needed...

38. Building a Tire Swing
What the customer
really needed...

39. Building a Tire Swing

40. Developing Software is Tough!

41. Developing Software is Tough!
• We are building something that doesn’t exist.

42. Developing Software is Tough!
• We are building something that doesn’t exist.
• Our customer is attempting to describe what they
imagine this non-existent product should be.

43. Developing Software is Tough!
• We are building something that doesn’t exist.
• Our customer is attempting to describe what they
imagine this non-existent product should be.
• We then try to imagine what they are describing.

44. Developing Software is Tough!
• We are building something that doesn’t exist.
• Our customer is attempting to describe what they
imagine this non-existent product should be.
• We then try to imagine what they are describing.
• We then try to build the product we believe we
heard them describe.

45. Developing Software is Tough!
• We are building something that doesn’t exist.
• Our customer is attempting to describe what they
imagine this non-existent product should be.
• We then try to imagine what they are describing.
• We then try to build the product we believe we
heard them describe.
• And finally, the first opportunity we have to
really see if we built a product that they need
and want is after we are done with
development.

46. Pop Quiz:
Waterfall Requirements Analysis

47. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
spent gathering, elaborating, and
communicating product requirements?

48. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?

49. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as
originally defined, change during the course
of the project?

50. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as
35% originally defined, change during the course
of the project?

51. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as
35% originally defined, change during the course
of the project?
What percentage of features, as ultimately
delivered, are rarely or never used by the
product’s end-users?

52. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as
35% originally defined, change during the course
of the project?
What percentage of features, as ultimately
65% delivered, are rarely or never used by the
product’s end-users?

54. Developing
Software
Is
TOUGH!

55. What is Agile All About?

56. What is Agile All About?
• A philosophy about software development.

57. What is Agile All About?
• A philosophy about software development.
• A collection of processes and practices that
uphold this philosophy.

58. What is Agile All About?
• A philosophy about software development.
• A collection of processes and practices that
uphold this philosophy.
• A grassroots movement to fundamentally change
the approach to software development.

59. What is Agile All About?
• A philosophy about software development.
• A collection of processes and practices that
uphold this philosophy.
• A grassroots movement to fundamentally change
the approach to software development.
“Agility is more attitude than process, more
environment than methodology.”

60. The Agile Manifesto

61. The Agile Manifesto
Individuals and interactions, over processes and tools.

62. The Agile Manifesto
Individuals and interactions, over processes and tools.
Working software, over comprehensive documentation.

63. The Agile Manifesto
Individuals and interactions, over processes and tools.
Working software, over comprehensive documentation.
Customer collaboration, over contract negotiation.

64. The Agile Manifesto
Individuals and interactions, over processes and tools.
Working software, over comprehensive documentation.
Customer collaboration, over contract negotiation.
Responding to change, over following a plan.

65. The Agile Manifesto
Individuals and interactions, over processes and tools.
Working software, over comprehensive documentation.
Customer collaboration, over contract negotiation.
Responding to change, over following a plan.
That is, while there is value in the items on the right, we
simply value the items on the left more.

66. Companies are Adopting Agile
Source: Dr. Dobb’s Agile Survey, 2008

67. Companies are Adopting Agile
• Agile adoption has increased in the last several years across
the globe.
Source: Dr. Dobb’s Agile Survey, 2008

68. Companies are Adopting Agile
• Agile adoption has increased in the last several years across
the globe.
• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
Source: Dr. Dobb’s Agile Survey, 2008

69. Companies are Adopting Agile
• Agile adoption has increased in the last several years across
the globe.
• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
• Respondents to a recent survey shared improvements in the
following areas after adopting an Agile development
approach:
Source: Dr. Dobb’s Agile Survey, 2008

70. Companies are Adopting Agile
• Agile adoption has increased in the last several years across
the globe.
• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
• Respondents to a recent survey shared improvements in the
following areas after adopting an Agile development
approach:
– Productivity (82%)
– Product Quality (77%)
– Stakeholder Satisfaction (78%)
– Reduced Costs (37%)
Source: Dr. Dobb’s Agile Survey, 2008

71. Why We Develop Software

72. Why We Develop Software
• We develop software for our customers’ benefit.

73. Why We Develop Software
• We develop software for our customers’ benefit.
• Change can be good. Change is usually the result
of new information and learning.

74. Why We Develop Software
• We develop software for our customers’ benefit.
• Change can be good. Change is usually the result
of new information and learning.
• The software we develop does not create value
for our customer at ‘point of plan’.

75. Why We Develop Software
• We develop software for our customers’ benefit.
• Change can be good. Change is usually the result
of new information and learning.
• The software we develop does not create value
for our customer at ‘point of plan’.
• An Agile approach may require us to be
comfortable with the traditionally
uncomfortable.

76. The BA’s Role on a Project

77. The BA’s Role on a Project
BABOK identifies the following:

78. The BA’s Role on a Project
BABOK identifies the following:
• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation

79. The BA’s Role on an Agile Project

80. The BA’s Role on an Agile Project
• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation

81. Agile: Enterprise Analysis

82. Agile: Enterprise Analysis
• Work with the customer to develop strategic
goals and a product vision.

83. Agile: Enterprise Analysis
• Work with the customer to develop strategic
goals and a product vision.
• Identifying the “value stream” for the proposed
product.

84. Agile: Enterprise Analysis
• Work with the customer to develop strategic
goals and a product vision.
• Identifying the “value stream” for the proposed
product.
• Brokering effective information exchange
between the customer and the IT team.

85. Agile: Enterprise Analysis
• Work with the customer to develop strategic
goals and a product vision.
• Identifying the “value stream” for the proposed
product.
• Brokering effective information exchange
between the customer and the IT team.
• The correct scope for Agile projects isn’t defined
requirements, but the well articulated product
vision.

86. Agile: Enterprise Analysis

87. Agile: Enterprise Analysis
“Quality in a product or service is not what the supplier
puts in. It is what the customer gets out and is willing
to pay for. A product is not quality because it is hard to
make and costs a lot of money, as manufacturers
typically believe. This is incompetence. Customers pay
only for what is of use to them and gives them value.
Nothing else constitutes quality.”

88. Agile: Enterprise Analysis
“Quality in a product or service is not what the supplier
puts in. It is what the customer gets out and is willing
to pay for. A product is not quality because it is hard to
make and costs a lot of money, as manufacturers
typically believe. This is incompetence. Customers pay
only for what is of use to them and gives them value.
Nothing else constitutes quality.”
- Peter Drucker

89. Agile: Enterprise Analysis
“Quality in a product or service is not what the supplier
puts in. It is what the customer gets out and is willing
to pay for. A product is not quality because it is hard to
make and costs a lot of money, as manufacturers
typically believe. This is incompetence. Customers pay
only for what is of use to them and gives them value.
Nothing else constitutes quality.”
- Peter Drucker
Simply stated, the customer defines quality.

90. Agile: Requirements Planning

91. Agile: Requirements Planning
• Requirements evolve with greater product
exposure.

92. Agile: Requirements Planning
• Requirements evolve with greater product
exposure.
• A lean principle: just enough, just in time.

93. Agile: Requirements Planning
• Requirements evolve with greater product
exposure.
• A lean principle: just enough, just in time.
• Requirements are planned for delivery in
time-boxed iterations.

94. Agile: Requirements Planning
• Requirements evolve with greater product
exposure.
• A lean principle: just enough, just in time.
• Requirements are planned for delivery in
time-boxed iterations.
• The development team creates and commits to
a definition of “done”.

95. Agile: Requirements Planning
• Requirements evolve with greater product
exposure.
• A lean principle: just enough, just in time.
• Requirements are planned for delivery in
time-boxed iterations.
• The development team creates and commits to
a definition of “done”.
• BA’s help to negotiate standards and the
specifics of product requirements.

96. Agile: Analysis & Documentation

97. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.

98. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?

99. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?
• How will your customer use your product?

100. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?
• How will your customer use your product?
• What are your customers priorities?

101. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?
• How will your customer use your product?
• What are your customers priorities?
• User Stories capture requirements using the
following form:

102. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?
• How will your customer use your product?
• What are your customers priorities?
• User Stories capture requirements using the
following form:
As a <user>, I want <product requirement>,

103. Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
• Who are your customers?
• How will your customer use your product?
• What are your customers priorities?
• User Stories capture requirements using the
following form:
As a <user>, I want <product requirement>,
so that <desired benefit>.

104. Agile: Analysis & Documentation

105. Agile: Analysis & Documentation
• Understanding “the why” can be as important as
“the what”.

106. Agile: Analysis & Documentation
• Understanding “the why” can be as important as
“the what”.
As an speaker, I want to
make my presentation
available to attendees
online, so that I do not
need to send it.

107. Agile: Analysis & Documentation
• Understanding “the why” can be as important as
“the what”.
As an speaker, I want to As an attendee, I want
make my presentation to download the
available to attendees presentation, so that
online, so that I do not I share what I have
need to send it. learned.

108. Agile: Analysis & Documentation
• Understanding “the why” can be as important as
“the what”.
As an speaker, I want to As an attendee, I want
make my presentation to download the
available to attendees presentation, so that
online, so that I do not I share what I have
need to send it. learned.
• Information gems exist in knowing why our
customers want what they ask for.

109. Agile: Requirements
Communication

110. Agile: Requirements
Communication
• The best method of conveying project progress.

111. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.

112. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.
• Emergent requirements.

113. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.
• Emergent requirements.
• The product backlog.

114. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.
• Emergent requirements.
• The product backlog.
• Burndown charts can help drive better project
decisions.

115. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.
• Emergent requirements.
• The product backlog.
• Burndown charts can help drive better project
decisions.
• Taskboards can visually radiate project progress.

116. Agile: Requirements
Communication
• The best method of conveying project progress.
• Building a better customer/IT relationship.
• Emergent requirements.
• The product backlog.
• Burndown charts can help drive better project
decisions.
• Taskboards can visually radiate project progress.
• Project documentation.

117. Agile: Assessment & Validation

118. Agile: Assessment & Validation
• Delivering the solution in small bites.

119. Agile: Assessment & Validation
• Delivering the solution in small bites.
• Reviewing requirements during planning.

120. Agile: Assessment & Validation
• Delivering the solution in small bites.
• Reviewing requirements during planning.
• Reviewing requirements during demo.

121. Agile: Assessment & Validation
• Delivering the solution in small bites.
• Reviewing requirements during planning.
• Reviewing requirements during demo.
• Requirements describe solution to business
needs.

122. Agile: Assessment & Validation
• Delivering the solution in small bites.
• Reviewing requirements during planning.
• Reviewing requirements during demo.
• Requirements describe solution to business
needs.
• Determining requirements as late as possible.

123. Agile: Assessment & Validation
• Delivering the solution in small bites.
• Reviewing requirements during planning.
• Reviewing requirements during demo.
• Requirements describe solution to business
needs.
• Determining requirements as late as possible.
• Validating requirements through prioritizing
delivery.

124. Business Analysts Are Crucial
To Agile Project Success

125. Business Analysts Are Crucial
To Agile Project Success
• Great products and happy customers begin and
end with pliable requirements.

126. Business Analysts Are Crucial
To Agile Project Success
• Great products and happy customers begin and
end with pliable requirements.
• Change happens, how do we embrace it?

127. Business Analysts Are Crucial
To Agile Project Success
• Great products and happy customers begin and
end with pliable requirements.
• Change happens, how do we embrace it?
• Expanding our toolkit, redefining nails as
opportunities.

128. Business Analysts Are Crucial
To Agile Project Success
• Great products and happy customers begin and
end with pliable requirements.
• Change happens, how do we embrace it?
• Expanding our toolkit, redefining nails as
opportunities.
• Continuous planning recognizes that change can
be good.

129. Wrap-Up

130. Wrap-Up
• Great BA’s assist the customer is defining the best
possible product, a standard consistently
examined during the entire project.

131. Wrap-Up
• Great BA’s assist the customer is defining the best
possible product, a standard consistently
examined during the entire project.
• Great products emerge from designs that evolve
as a result of information made available to the
customer and project team.

132. Wrap-Up
• Great BA’s assist the customer is defining the best
possible product, a standard consistently
examined during the entire project.
• Great products emerge from designs that evolve
as a result of information made available to the
customer and project team.
• Great project teams promote open and honest
communication, and utilize this information to
tune their behavior.

133. Questions and Answers
• Previously submitted.
• From the attendees.

134. Meeting Close
• Thank you.
• Bill Gaiennie, Davisbase Consulting
• bill@davisbase.org
• http://www.davisbase.org
• (949) 303-9109