Rainer Wendt discusses how business analysts working in the product owner role can help put more business in the driver's seat of agile projects. As product owners from business often lack time and experience to fully own the product backlog, business analysts can support them by defining user stories, acceptance criteria, prioritizing requirements, and facilitating collaboration between business stakeholders and the development team. This shared product owner/business analyst model helps address the common dilemma of part-time product owners from business and bridges communication between business and IT for effective agile delivery.

1. More Business in the
driver’s seat
Rainer Wendt
President of the IIBA Chapter Germany
Business Analysts working in the Product Owner Role

2. Your Speaker today
Rainer Wendt, PMP, CBAP, PMI-PBNA, SCT
Study of Electrical Engineering in Aachen
25+ years of international IT Experience
- Software development in the Nineteenths
- Project Lead in Telecommunications and Banks & Insurances
- Requirements Engineering, Business Analysis
- Risk Management
- Change Management
- Training, Coaching
- Etc.
Managing Director masVenta Business GmbH
President IIBA Chapter Germany

3. Agenda
• Introduction
• Agile Practices are Imperative!
• How to engage Business
• How can I sell “Agile”?
• The Product Owner Dilemma
• The Agile Business Analyst

4. Agile Practices are Imperative!
• As the customer (Business) does not know what is
needed or they do not have the skills to document it
appropriately
• As much knowledge necessary to formulate and analyze
requirements starts to exist during development
It is close to
impossible to
understand all
requirements before a
development start
• Longer project duration cannot be avoided
• Project cost and TCO are increasing, cannot be
predicted and deviate significantly from
planning
In case you need to stick
to the Waterfall model,
expensive change
requests cannot be
avoided

5. 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.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
That is, while there is value in the items on
the right, we value the items on the left more.
http://agilemanifesto.org

6. Roles and Responsibilities in Agile Context
ScrumMaster
Product Owner
Scrum Team
StakeholdersSponsor
Business AnalystProject Manager
Source: Watermark Learning

7. What does Business understand under „Agile“?
?
?
?
?
?
?
?

8. Agenda
• Introduction
• Agile Practices are Imperative!
• How to engage Business
• How can I sell “Agile”?
• The Product Owner Dilemma
• The Agile Business Analyst

9. Is „Agile“ good or bad for my project?
Some typical concerns from Business perspective
• More work for us!
• Developer anyway do what they want to
do – Business can hardly steer them
• Documentation mostly „too lean“ and
this insufficient for Compliance and Audit
purposes
• Deliverables are not exactly specified in
the contract
• Not all bespoken deliverables will make it
• High risks with T/M as well as Fixed Price
• More involvement for us!
• Business will always set priorities – for
each sprint
• „Changes are always welcome“ – we can
change - whenever we want
• Ready-to-use features will be available
after each Sprint
• Fail Fast: If the results of a sprint are not
good, the loss is limited
• We will be working in one team without
boundaries between customer and
vendor

10. • More involvement for us!
• Business will always set priorities – for
each sprint
• „Changes are always welcome“ – we can
change - whenever we want
• Ready-to-use features will be available
after each Sprint
• Fail Fast: If the results of a sprint are not
good, the loss is limited
• We will be working in one team without
boundaries between customer and
vendor
What attitude will the stakeholder have?
Which influence factors set the initial mindset re. „Agile“
• More work for us!
• Developer anyway do what they want to
do – Business can hardly steer them
• Documentation mostly „too lean“ and
this insufficient for Compliance and Audit
purposes
• Deliverables are not exactly specified in
the contract
• Not all bespoken deliverables will make it
• High risks with T/M as well as Fixed Price

11. Typical influence factors are:
• Trust in the Agile Team
• Trust in the capabilities and skills of the Agile Team
• The risk of the project (Impact x Probability)
• Experiences with former agile projects
• Dominant power of opinion of the colleagues, especially of the boss
• Open-mindedness towards new things
• Striving for success vs. angst for failure
• Training and education, knowledge sovereignty
What attitude will the stakeholder have?
Which influence factors set the initial mindset re. „Agile“

12. Agenda
• Introduction
• Agile Practices are Imperative!
• How to engage Business
• How can I sell “Agile”?
• The Product Owner Dilemma
• The Agile Business Analyst

13. How can I sell „Agile“ successfully?

15. Open mindedness and honesty (1/2)
• Requirements are no longer fixed upfront,
but resources and time
• Changes or Re-work might have
consequences – like non-implementaion
of low-prio requirements

16. Open mindedness and honesty (2/2)
From Ryan Matena, Ready for Agile, Projects@Work.com, 9/28/06
Ressources
& Time are
uncertain Finale Scope is
uncertain

17. Transparency
• Explain the Agile Way and adaptations, e.g. how ceremonies like Daily
Stand-Ups are taking place in real-life
• Simplify, get rid of complexity like over-engineered reporting Excels
• Simple Backlog, Burn-Down
Chart, Issue Tracker, Risk Register
• Communicate plan deviations in
a clear and transparent way
• Make reporting artefacts easily
accessible to stakeholders

18. References
• Show-case about successful „Lighthouse-Project“
• Try to engage a well-known agile team
• Walk through reporting artefacts of the
project
• Describe authentic actions taken on plan
deviations
• Report real cost saving due to Agile
• Errors and Lessons Learned
• What has not been implemented?

19. Knowledge Transfer
• Professional Trainings for the Business, e.g. Product Owner in SCRUM
• Help Business in writing exemplary Backlog Items (User Stories) and
Acceptance Criteria
• Ensure that Business
stakeholders will have the
capabilities and the
responsibility for the
continuous prioritization of the
Backlog items

20. Agenda
• Introduction
• Agile Practices are Imperative!
• How to engage Business
• How can I sell “Agile”?
• The Product Owner Dilemma
• The Agile Business Analyst

21. The key person in the
Business:
The Product Owner

22. The Dilemma of the Part-Time-PO
A Product Owner from Business can
hardly dedicate 100% of his capacity to
the project
The day-to-day Business has normally
priority
Product Owners from the Business are
often lacking experiences and skills in
agile Projects
Orientation is difficult

23. A PO-Team as solution
Several team members with BA skills can work with
the Lead Product Owner on the following tasks:
• Defining user roles and personas
• Eliciting requirements from stakeholders and users
• Defining user stories and acceptance tests
• Helping the PO prioritize and manage the Product
Backlog
• Facilitating user story workshops
• Building requirements runway for upcoming iterations
• Identifying themes for releases
• Contributing to release and iteration planning
• Identifying and estimating business analysis tasks
• Analyzing business and technical impacts of
requirements
Source: Watermark Learning

24. The PO-Team
(An Example)
I am the
Lead PO
I am a
Business
Analyst
I am a
Dev SME
The Lead PO from the
Business has the final say re.
the value-oriented
prioritization
The Business Analyst
manages the Backlog
The Business Analyst
formulates User Stories and
Acceptance Criteria
The Development Subject
Matter Expert gives advice
re. technical dependencies,
feasibility and risk

25. Agenda
• Introduction
• Agile Practices are Imperative!
• How to engage Business
• How can I sell “Agile”?
• The Product Owner Dilemma
• The Agile Business Analyst

26. The Agile Business Analyst (BA)
• The Product Owner (PO) is often focused on strategic, product
and release-level activities
• Preparing the business case, analyzing the market, defining
the product roadmap, and defining release plans
• A Business Analyst can supplement the PO with a focus on
tactical, iteration-level activities
Source: Watermark Learning

27. Applied SCRUM
• Typically in real life, the Business Analyst has the role of the Product Owner or (s)he
supports the PO, especially if the contribution of a Business-PO is not sufficient
• Requirements from the Product-Backlog are being planned according to criteria like
priority, stability etc by the PO/BA „on behalf of Business“
• The Business Analyst in his PO role is mostly a „Communication Facilitator“
Business Analyst / Product
Owner
Source: German Wikipeda
Business

29. Summary
• Trust is the foundation for Agile Practices
• Trust can be built through Honesty,
Transparency and Knowledge
• The Product Owner in Business needs support
for the continuous elicitation and prioritization
of the requirements (User Stories)
• Business Analysts from IT can provide this
support which helps bridging the gap between
Business and IT

30. More Business In The Driver Seat!
Any Questions?