The document discusses the changing role of a business analyst in agile software development. It begins by describing the traditional responsibilities of a business analyst, which include requirements gathering, documentation, and testing. It then introduces agile methodologies, noting that they focus on iterative development and user involvement. In agile, the business analyst's role evolves into that of a product owner, whose key responsibilities are prioritizing the product backlog, managing scope, and engaging with users and stakeholders. The presentation demonstrates artifacts like user stories, backlogs, and wireframes that a product owner would manage. It concludes with best practices like defining scope, conducting usability testing, and obtaining continual user feedback.

1. Making IT work for you!
Call me a Product Owner!
Role of Business Analyst in the Changing Times of Agile Software Development
Technology Experience
Pardha Saradhi Mantravadi

2. Agenda
Image Courtesy – Modernanalyst.com

3. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

4. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

5. What /Who is a ‘Traditional BA’?
Traditional Business Analyst

6. Traditional Business Analyst

7. What /Who is Traditional BA
A business analyst…
• works as a liaison among stakeholders
• in order to elicit, analyze, communicate and validate
requirements for changes to business processes, policies
and information systems.
• understands business problems and opportunities in the
context of the requirements
• recommends solutions that enable the organization to
achieve its goals.
- As Per IIBA’s BABOK ver 1.6

8. What’s in a Name
• Business Analyst – (Banking, Inventory, Insurance…)
• System Analyst
• IT Business Analyst
• SME (Subject Matter Expert)
• Business Consultant
• Product Manager

9. What Does a BA Do
• Enterprise analysis
• Requirements planning and management
• Requirements elicitation
• Requirements analysis and documentation
• Requirements communication
• Solution assessment and validation
Technology
People
Functionality
Areas as per IIBA’s BABOK ver 1.6

10. What Does a BA Do
Deployment View
Component View
Use Case View
Logical View
Process View
Problem Domain
Platform Independent
Model (PIM)
Analysis
Solution Domain
Platform Specific
Model (PSM)
Design
Focus on this

11. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Pre-sales:
• Feasibility study
• Cost-benefit Analysis
• Study alignment of project’s
goals with Organization’s goals
• Proposal / RFX

12. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Requirements Development
• Requirements Planning
• Elicit requirements
• Define/specify requirements
• Document requirements
• Communicate requirements

13. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Test Plans &
test cases
Test Plans and test cases
• Create system test cases
• Assist testers in creating test
plans
• Traceability from requirements
to test cases

14. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Test Plans &
test cases
Design
• Create Prototypes
• Help in creating UI specification
• Assist and assess in creating the
architecture so that it supports
functional and non-functional
requirements
Design

15. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Test Plans &
test cases
Design
System Testing
• Conduct system testing
• Generate test reports
• Assist the team in fixing the defects
System testing

16. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Test Plans &
test cases
Design
System testing
Acceptance Testing
• Assist customer in acceptance
testing
• Generate acceptance test reports
• Assist the team in fixing the defects
Acceptance testing

17. Responsibilities /Expectations of a BA
Pre-sales
Activities in Project Life Cycle
CompletionofProject
Requirements
Development
Test Plans &
test cases
Design
System testing
Acceptance testing
Project closure
• Get signoff from customer at various
relevant milestones
• Assist team and PM in closing the
project with acceptable customer
satisfaction
Project closure

18. Responsibilities /Expectations of a BA
Activities in Project Life Cycle
CompletionofProject
Pre-sales
Requirements
Development
Design
Test Plans &
test cases
System testing
Acceptance testing
Project Sign-off
CompletionofProject
Requirements Management
Requirements Management
• Manage change requests
• Work with team on impact analysis
Decide on Go/ No-go for changes
• Two-way Traceability (top-down and
bottom-up)
• Multi-level traceability management
Requirements
Development
Design
Test Plans &
test cases
System testing
Acceptance testing
Project Sign-off

19. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

20. What is this Agile all about
Agenda

21. • Documents, documents and more documents
• Wait till they are frozen
• Corrections, rework, changes and more
Traditional BA Process

22. Docu’mentality’
Image Courtesy – Modernanalyst.com

23. Rework is the only Reward
Image Courtesy – Modernanalyst.com

24. Team work
Image Courtesy – Leigh Rubin

25. Traditional Software Development Methdology
Functional
& Technical
Requirements
Architecture
&
Tech. Design
Coding
Functional
Testing
This methodology does not work! Why?
Why Agile

26. Traditional Software Development Methodology
The User is not kept in the loop throughout
the product development life cycle.
When the product is released, he/she is surely not too happy! 
Why Agile

27. Agile Software Development
User
Knowledge
This Methodology works wonders! Why? 
Functional
& Technical
Requirements
Architecture &
Technical
Design
Coding
Functional &
System Testing
User Testing Improvement
1
Agile Development Methodology

28. Agile Software Development Methodology
Not just technology and functional needs are addresse, but user’s
needs are taken care of too!
User has been listened to and cared for, so he/she is happy!
Why Agile


29. • Early visibility
• Better control
• Deliver what is Important and Urgent
• Support from Senior Management
Customer
• Commit what can be delivered
• Better control on resources
• Manage scope and releases
• Minimize Customer-reported defects
Benefits of Agile Processes
Why Agile
Product Developer

30. Pick the Best Approach
• SCRUM
• Extreme /Paired Programming
• User Stories and User Story Cards
• Test Driven Development
Agile Development Process

31. The Agile Manifesto
Agile Development Methodology
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over
Source - www.agilemanifesto.org

32. One of the Agile Development Methodologies
• Mature team members who can organize themselves
• Product is built over a series of sprints (4-6 weeks cycle)
• Requirements are initially spelled out as items in product
backlog.
• Focus is more on processes aligned to the fitment of the
organization, product, team etc.
SCRUM Defined

33. SCRUM Defined
Source - Mountain Goat Software

34. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

35. Once an Analyst – always an Analyst
Agenda

36. • SCRUM Master
• Product Owner
• Team (Feature Team)
Changing Role of a BA
SCRUM Roles

37. • Who is the real Product Owner?
• In client’s location, Product Owner or Customer
Proxy is the primary scope manager
• Business Analyst in the product development team
(Offshore) acts as a proxy to Product Owner onsite
• With scoping and product-related decisions,
traditional Offshore BA is transforming into a Product
Owner
Changing Role of a BA
From a Business Analyst to a Product Owner

38. Usability Testing
Product Owner’s Primary Focus

39. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

40. What does a Product Owner do
Agenda

41. • Maximize ROI on the product
• Maximum business value
• Minimize product development cost
• Scope and Prioritize
• Committed in decisions on product features
• Interact with development team
• Interact with stakeholders
• Interact with users
Responsibilities of a Product Owner

42. Primary Activities
Stakeholder interactions
User studies/interactions
User Testing
Responsibilities of a Product Owner
Product Backlog(Scope)
User Stories and Cards
Test Cases/

43. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

44. • Product Backlog
• User Stories
• User Story Cards
• Wireframes
• Estimates ( Contribute as part of team)
• Reviewed System Test Plans / System Test Cases
Deliverables of a Product Owner

45. Product Backlog
• Repository of all features/potential requirements
• Laundry-list maintained through-out the life cycle
• One-liner descriptions of the features
• Priorititization is the key
• MoSCoW
– Must
– Should
– Could
– Won’t Need
Deliverables of a Product Owner

46. User Stories
• Features written from the perspective of users
• Still abstract features, possibly one-two liners
• Grouped under ‘themes’
• User story In the format
– As a <User Type>
– I wish to <do some task/action>
– So that I can <get some benefit>
Deliverables of a Product Owner

47. User Story Cards
• Detailed versions of user stories
• Each user story has at least one user story card
• Details the following:
– Business criteria
– Acceptance Criteria
– Scenarios
– Data definitions
– Wireframes / mock-ups
Deliverables of a Product Owner

48. Wireframes
• Rough sketch /presentation of functional flow
• Not actual visual design
• Low-fidelity UI prototype
• Can be created in the following formats
– Microsoft Visio
– Adobe Photoshop
– Microsoft PowerPoint
– Microsoft Excel
– Paper sketch
Deliverables of a Product Owner

49. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

50. Show & ‘Tell me How!’
Agenda

51. Show documents and artifacts from the four projects:
• One-liner requirements
• Mindmap.pardha
• Stakeholder interactions reports
• User studies reports
• Feature list_Product backlog
• User stories list
• Wireframes
• User story cards
Deliverables of a Product Owner

52. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

53. User is the Driver!
Project Failure Factors
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
11. Other 23.0%
Standish Group Report, CHAOS

54. User is the Driver!
Project Success Factors
1. User Involvement 15.9%
2. Executive Management Support 13.9%
3. Clear Statement of Requirements 13.0%
4. Proper Planning 9.6%
5. Realistic Expectations 8.2%
6. Smaller Project Milestones 7.7%
7. Competent Staff 7.2%
8. Ownership 5.3%
9. Clear Vision & Objectives 2.9%
10. Hard-Working, Focused Staff 2.4%
11. Other 13.9%
Standish Group Report, CHAOS

55. Time ’boxing’
Stick to the timeboxes

56. • Define what is in Scope
• More importantly, define what is ‘out of Scope’!
• Freeze Scope for the sprint
• Socialize with stakeholders and team members
Scope, De-scope , Re-scope
I don’t know the key to success, but the key to failure
is trying to please everybody – Bill Cosby

57. Understand and Communicate
If you can’t explain it simply,
you didn’t understand it well enough!

58. Follow Standards – Use Templates

59. Usability Testing
• Learn how to use the product
• Features are important
• But, users’ tasks are more important
Think Product , not Project!
Product usage and features

60. • Connect with customers and users
• Connect frequently
• Get continual feedback
• Plough the feedback into the product development
Know your customers and users
Customers always know what’s wrong. They can’t
always tell you what they want, but they always can
tell you what’s wrong
- Carly Fiorina

61. • Draw, don’t just write
• Wireframes, sketches, box-and-arrow diagrams
• Low-fidelity UI Prototypes
• Re-work, improve and get approval
Show and Tell
A picture is worth thousand words, an interface is
worth thousand pictures – Ben Shneiderman

62. Usability Testing
• Flow diagrams
• Discussion points
• Ideas, draft plans, approaches
• Thoughts and dreams
• Applications’ interface
Take lots of photos
Snaps, videos and screen-grabs

63. Agenda
• Traditional BA - Responsibilities and expectations
• Agile development methodology and current trends
• Changing role of BA in Agile Methodologies
• Responsibilities, Expectations of a Product Owner
• Deliverables of a Product Owner
• Demo of Product Backlog, User Stories and User Story Cards
• Do's and Don'ts from my experience
• Discussion - Q & A

64. Thank You
Mail : pardhas@texavi.com
pardha.mantravadi@gmail.com
Mobile : +91 9819057757
Twitter : @pardhas
LinkedIn : pardhasaradhimantravadi
Blog : http://texavi.com/blog
Web site : www.texavi.com
Connect