This document compares traditional roles to agile roles on a project. It outlines the differences between a traditional sponsor and product owner, project manager and scrum master, business analyst and agile business analyst, tester and agile tester, and developer and agile developer. For each role, it provides 3-4 bullet points describing the key responsibilities and approach in traditional versus agile frameworks. The document is intended to help people understand how roles change and adapt when moving from traditional to agile methodologies.

1. Traditional Roles
vs.
Agile Roles

2. Agenda
Compare the Traditional Roles vs. Agile Roles
1. Sponsor vs. Product Owner
2. Project Manager vs. ScrumMaster
3. BA vs. Agile BA
4. Tester vs. Agile Tester
5. Developer vs. Agile Developer
2

3. Agile Team Structure
3

4. Traditional Sponsor





Projects have one sponsor, usually higher in the organization
chart, funds the project but is not involved in the details.
Multiple business stakeholders are involved to provide input
and requirements.
No one decision maker.
Engaged at the start of the project and then towards the end
during testing.
Usually receive weekly status reports from PM on how the
project is doing and if any issues need their attention.
4

5. Product Owner







Person in charge of the product backlog i.e. requirements.
Prioritizes the backlog stories based on business value.
Most likely from the business.
Accepts or rejects work completed.
Knowledgeable, Empowered and Engaged.
Only one who can add or remove stories from the backlog.
Owns final success or failure of project.
5

6. Traditional Project Manager







Manages the project through developing detailed project plans
upfront at the task level.
Heavy upfront planning, may engage key SMEs for estimates or
provide ones themselves.
Manages tasks, holds weekly status meetings.
Takes care of addressing any major team issues.
Maybe managing several projects at a time.
Accountable for project success and failure.
May use Command and Control to tell team what to work on
next and by when to get it done.
6

7. 





The ScrumMaster
Is a ‘Leader’ of the team who creates a culture of high collaboration, team
empowerment, and high visibility and accountability. Owns the ‘Process’.
Engages the product owner and business SMEs upfront to develop the
product backlog. Holds product owner accountable for owning the backlog.
Is knowledgeable on Agile Requirements Gathering methods and Story
identification, breakdown and estimation techniques.
Very light use of project management tools. Spends most of their time with
the team and removing impediments.
Heavy initial release planning then continuously engages team to update the
plan each sprint.
Holds daily 15 minutes standup meeting with all team members involved
including the product owner.
7

8. The ScrumMaster…cont’d







May manage only one large project or a couple of smaller
projects at one time.
Is not accountable for project success and failure.
Uses a Servant Leader style for leading the team. This results in
self organizing, empowered and accountable teams.
Empowers the committed team members from Business and IT
to make decisions. Does not make business or technical
decisions on behalf of them.
Understands and has experience with iterative delivery of
projects with focus on Business value.
Measures and reports progress frequently using easy to
understand burn down charts.
May hold Certified ScrumMaster certification.
8

9. Traditional Business Analyst







Analyze business need to help identify business problems and
proposed solutions.
Acts as liaison between the business and IT.
Will meet with various stakeholders at the beginning of a
project to elicit requirements in detail.
May use Use Case specifications or other type of documentation
to capture all requirements.
May require business to sign off on requirements upfront on a
project.
Probably trained on upfront detailed requirements gathering as
opposed to iterative requirements elaboration.
Collaborates on the project heavily upfront then again during
testing to validate requirements were met and possibly during
development to clarify ambiguity.
9

10. The Agile BA

The BA/SA is the owner of requirements documentation and
elicitation.

They are a master of Agile Requirements Gathering and know how to
break down stories into small valuable chunks.

Understand how to capture stories, user test cases, business rules,
process diagrams, UI prototypes and other artifacts.

An Agile BA engages the business SMEs and product owner with the
team instead of acting as a liaison/middleman to the business.

They manage the backlog of stories by adding, removing, updating
stories there (after Product Owner approval) and keeping it up to
date.

They will schedule and facilitate requirements elicitation sessions and
make sure the right SMEs are invited.
10

11. The Agile BA…cont’d

They will make sure that all scope changes have been appropriately
captured and documented on the backlog.

During the iteration, the BA works on making sure the
requirements and acceptance criteria are understood by
developers for all stories.
They are very effective Facilitators and know how to bring the
team to their goals from any session.
They work ahead with the product owner to define stories and
test cases for the next iteration.
The work closely with testers (IT or business) to track testing
progress.
Use light weight, easy to read, and accessible documentation.
They make sure the right individuals are using the artifacts
produced.




11

12. Traditional Tester







The testing group is usually engaged towards the end of the
project.
This group may require upfront complete documentation on
requirements in order for them to develop test cases.
Work closely with the BAs to clarify missing requirements.
Use of issue tracking tools to log bugs and get them assigned to
developers in addition to tracking their status.
May use heavy weight testing tools to document and manage all
test cases and track progress on each one.
May use automated testing and load testing tools.
Traditionally they have final say on if the software is ready to be
tested by the customer or move into production.
12

13. The Agile Tester







Engaged early during the project, part of the core team. Could be a
business user tester or a QA test engineer or have both.
Uses automated testing whenever feasible.
QA test engineers work ahead of the next iteration to help setup test
data, help identify additional test cases needed.
During each iteration QA testers work closely with developers to
know when stories are ready for their initial testing.
They perform testing, log and track issues and provide feedback to
developers.
They keep track of where each story is at in terms of testing and how
close it is to ‘Done’ and may send out daily emails with progress.
They collaborate with the team daily during the 15 minute standup.
13

14. Traditional Developer







Engaged on the project after planning has been completed and the
project is ready for development.
Is expected to read the documentation on requirements to
understand what the software needs to do. Goes through BA for
additional questions.
Works of the upfront designs produced by the architect.
Does not usually have access or care about test cases. Driven more
by requirements documented by BA.
May or may not be aware and follow company coding standards
and architecture best practices.
Mostly works independently. May get assigned tasks from PM with
specific due dates.
Mostly works vertically focusing on ‘Front end’ ‘Business logic’
‘Data logic’ areas instead of horizontally focusing on each business
story.
14

15. The Agile Developer





Engaged from the beginning of the project. Helps story sizing,
dependency identification and initial release planning.
During each iteration, the developer is working on
understanding requirements and using Test Driven
Development as a method of implementing them.
They create automated unit tests for each test cases and may
use mock data when real data is not readily available or to
reduce dependencies.
They frequently check in their code and aim for continuous
integration.
They must focus on one story at a time and work Horizontally
instead of the typical Vertical way we worked in waterfall.
15

16. The Agile Developer…cont’d




They follow the company’s coding standards and recommended
designs.
They work closely with the user on testing each story as it
passes a few test cases or become ‘Done’.
They raise issues and impediments daily and only work on the
most valuable stories and tasks.
They are engaged, flexible, collaborative, quality driven and
focused on the iteration goal.
16

17. Thank You!
Prepared by: Sumit Mahajan
17