In Agile/Scrum the skills of a BA are still needed, especially in more complex efforts. This describes BA skills applied in Agile. Should the BA be a Product Owner? On the scrum team?
1. The role of the BA in Agile
Software Development
IIBA Central Indiana Chapter - Jan 2016
2. Introduction
In which, we discuss what is Agile, what is Scrum, and where
Business Analyst fits in.
I’ve been a Developer, a Project Manager, a Product Owner, a
Business Analyst, a Development Team Manager and a
Consultant. I have a special interest in Lean and Agile
application development.
John Durgin, CBAP, MBA, CSM, CSPO
4. A formal definition
Agile is a collection of values and
principles expressed in the Agile
Manifesto for Software
Development.
Scrum is a development framework
based on empirical process control
wherein cross functional, self-
organizing teams deliver working
software every 30 days or less.
Sprint
RetrospectiveModify
5. The Agile Values
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
value the items on the left more.
http://www.agilemanifesto.org/
6. Scrum Roles
Scrum Master -The Scrum Master is responsible for ensuring Scrum is understood
and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum
theory, practices, and rules.
Product Owner -The Product Owner is responsible for maximizing the value of the
product and the work of the Development Team. How this is done may vary widely across
organizations, Scrum Teams, and individuals. The Product Owner is one person, not a
committee. The Product Owner may represent the desires of a committee in the Product
Backlog, but those wanting to change a Product Backlog item’s priority must address the
Product Owner.
Development Team - The Development Team consists of professionals who do
the work of delivering a potentially releasable Increment of “Done” product at the end of
each Sprint. Only members of the Development Team create the Increment.
9. Project Constraints
Traditional: Software
Projects
Scope and Time are fixed.
The job of the Project
Manager is to manage
resources and budget.
Scrum: Product Development
Time and Resources are fixed
The job of the Product Owner
is to manage scope.
11. The Business
Analyst vs.
Product Owner
The BA defines and
manages the product
requirements: the “what”
The Product Owner
defines and manages
scope: also the “what”
12. What is Business Analysis?
Business analysis is the practice of enabling change in an enterprise by
defining needs and recommending solutions that deliver value to
stakeholders.
Business analysts are responsible for discovering, synthesizing, and
analyzing information from a variety of sources within an enterprise, including
tools, processes, documentation, and stakeholders. The business analyst is
responsible for eliciting the actual needs of stakeholders—which frequently
involves investigating and clarifying their expressed desires—in order to
determine underlying issues and causes.
None of this changes in Agile
13. What do they do?
Business analysts play a role in aligning the designed and delivered
solutions with the needs of stakeholders. The activities that
business analysts perform include:
• understanding enterprise problems and goals,
• analyzing needs and solutions,
• devising strategies,
• driving change
• facilitating stakeholder collaboration.
None of this changes in Agile
14. Business Analyst Roles in Agile
From the BABOK Agile Extension:
● The analyst might act as the product owner/customer
representative where they are empowered by the business to make
decisions on product features and priority.
● The analyst could act as a surrogate product owner, in situations
where the business product owner is not available.
● The analyst might act as the second in command to a business
product owner with limited availability.
The Agile Extension lists numerous other roles, all peripheral to, and in
support of the product owner.
15. Product Owner Responsibilities and Skills
The Product Owner must... Skills required
Understand the Business Need Facilitation, Elicitation, Analysis, Enterprise Analysis, Strategy, Business Value,
Relationship Building
Create a Vision Analysis, Consensus Building, Clarity
Develop a Roadmap Planning, Alignment (with strategy, goals), release planning
Backlog Refinement Prioritizing, functional decomposition
Challenging and Motivating the Team Leadership, Knowledgable, Available, Integrity, Building Trust
Make Decisions Take Initiative, Domain Expert, Relationship Building with Stakeholders, Empowered
Define Acceptance Criteria Analysis, Clarity, SME
Single Wringable Neck Take Ownership, Accountable
16. Desirable Characteristics of a PO
● A Visionary and a Doer
● Leader and Team Player
● Communicator and Negotiator
● Empowered and Committed
● Available and Qualified
● Spends half the time with users, business leaders, and IT leaders.
● Spends the other half working closely with “the development team”
clarifying specifications.
As a BA, how are doing in these areas?
17. A Successful Product Owner...
● Is always thinking of business value.
● Encourages and Leads the Development team by Communicating Vision
● BUT, is not the sole source of that vision. It must be collaboratively
developed and widely shared.
● Clarifies business/user needs to development teams so that uncertainty
is removed and developer velocity is maximized
● Prioritize, Prioritize, Prioritize
How are your skills?
18. On any given non-trivial project the BA
skills and availability of the Product
Owner will be critical to project success.
If the PO is not so equipped, a BA can
help make a project successful
21. Business Planning
Level Roles Involved Result
Strategic C-Level Management Business Plan
Functional
Alignment
CIO, CTO, Business Leadership IT Roadmap
Solution Alignment Functional Directors
Product Owner, Business Analyst
Product Roadmap
Solution Definition Product Owner, BA, Stakeholders Product Backlog
Sprint Planning Product Owner, BA, Dev Team Sprint Backlog
22. The Business Analysis Process (traditional)
Problem or
Opportunity
Identified
Functional
Decomposition
Detailed
Requirements
Solution
Selection
Roadmap to
Solution
Prioritization
In Scrum, functional decomp results in “Stories”, which get prioritized
23. BA Techniques - User Stories
Note: The concept of user stories is not defined by Scrum. It comes from XP.
● Card, Conversation, Confirmation (Ron Jeffries, Extreme Programming)
○ As a <role>, I want to <do>, so that I can <get value>
○ The user can <do something>
● It’s about the goal, not solution attributes
● Story Design - Independent, Negotiable, Valuable, Estimable, Small,
Testable
No, there is not a 1-to-1 between user stories and functional requirements.
24. How to Build a MVP
stories not
Independent
Independent
minimum viable product
25. Good User Stories
❖ Negotiable:
➢ The “story” is a reminder to have a discussion
➢ stuff may change, don’t write too much
❖ Valuable:
➢ Stories need to reflect business goals
➢ The PO is accountable for determining value
and adding to the product backlog
➢ Learn about story mapping ( that is whole talk
in itself)
Independent
Negotiable
Valuable
Estimable
Small
Testable
26. Good User Stories
❖ Estimable:
➢ If the team is having difficulty, likely the story
is too large or complex or calls for technology
that the team has no expertise in
❖ Small:
➢ Story Slicing
➢ vertical slice = independent
➢ adding details = acceptance criteria
❖ Testable:
➢ if you’ve got some good ACs
➢ make sure details add definition, not scope
Independent
Negotiable
Valuable
Estimable
Small
Testable
28. Acceptance Criteria
Back of the “card”, capture detail (Confirmation)
Different takes on how to use acceptance criteria
1. Try it with <different data>
2. I can <variations on the function>
3. define parameters of the function
4. define when the story is complete
5. function is working as expected
AC are NOT tests. They can point to the need for certain tests.
30. "There are lots of people who believe their job is
collecting and communicating requirements. But
it's not. The truth is, your job is to change the
world. Every great idea you turn into a product
solution changes the world in some small, or not
so small, way for the people that use it."
- Jeff Patton, author of “User Story Mapping”
31. Follow-Up
Reading
Some books I highly recommend:
User Story Mapping - Jeff Patton
Agile Product Management with Scrum - Roman Pichler
User Stories Applied - Mike Cohn
34. The
Marshmallow
Challenge
an exercise in agile development
tools: 1 marshmallow, 12 sticks of spaghetti, and a
3’ length of painter’s tape
The object of the game is to build the
tallest freestanding structure of
spaghetti and place the
marshmallow on top.
Teams: 3-4 people each
Team formation, roles and
responsibilities: 1 minute
Then 14 minutes to build a solution