Overview of Agile for Business Analysts

Presenter: Sally Elatta

Overview of Agile & Scrum

For Business Analysts

1

About the Speaker

• Sally Elatta

• Founder of AgileTransformation.com

• Enterprise Process Improvement Coach, Architect, Trainer

• Coached over 18 teams on adopting Agile methods.

• Taught over 600+ students on Agile

• Certified ScrumMaster, Scrum Practitioner, IBM, Sun, and

Microsoft Certifications.

• [email protected]

• 402 212-3211

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com2

mailto:[email protected]

• Quick overview of Traditional Development

• Provide an overview of Agile, Scrum

• Overview of the Agile Roles

• Focus on the BA Role

• Overview of the basic process

• Why it‟s being adopted

• Resources

Session Goals

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com

3

4

The Waterfall Process


4

Waterfall Characteristics

5Copyright(c) Sally Elatta 2009 www.AgileTransformation.com

The manifesto‟s shared value statement:“We are uncovering better ways of developing software by doing it and

helping others do it. Through this work we have come to value:

Individuals & interactions Over Processes & 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.”

The Agile Values


7

Project Management Principles

(Release Planning, Sprint and Iteration Planning, Daily Scrum,

Sprint Demo and Retrospective ..etc)

Engineering Principles(TDD, Continuous Integration,

Refactoring ..etc)


8

Agile Characteristics Product Backlog

Test Driven Development Business / IT as One Team9


Committed:

– Scrum Master

– Product Owner

– The Team

Interested:

– Stakeholders

– Users

Agile/Scrum Roles


10

11

Who is the Product Owner?

1 Person in charge of the backlog!

Prioritizes the backlog stories for highest ROI.

Most likely from the business. Has the mostto loose/gain from project outcome.

Accepts or rejects work completed.

Knowledgeable, Empowered, Engaged

Only one who can add or remove stories from the backlog.

The Captain of the Ship! Owns final success or failure of project.

Can stop the project if no ROI is being delivered.


11

Product Backlog

BA and Product Owner Collaboration

• Much of our project 'Waste' is a result of :

– Missing stories

– Mis-understood stories

– Team working on non-valuable stories

– Business changing their mind on what

they want in a story

• The BA‟s role is to address all these issues by

engaging the product owner early and often.


12

The ScrumMaster

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com13

• Is the owner of the “Process”.

• Attacks impediments like a hawk!

• Makes sure the team is getting the

business collaboration needed for success.

• Helps build teamwork, motivation and

create self organizing teams.

• Prepares 'visual' reports that represents the

teams progress.

The Team

• Small, cross-functional group of people that work

together daily. Size is 7 (+- 2)

• Team is made up of developers, analysts,

testers, business users, data and systems folks

..etc.

• Some members are dedicated (75%+) and

some are shared with other projects.

• Each member attends all the core meetings,

breaks down and estimates tasks.


14

Business Users and SMEs

• Help Product Owner and Team by: Identify User Acceptance Test cases ahead of each

planning meeting.

Answering team questions and being a business SME.

Help define priority and work that will provide most value.

Perform user acceptance testing and recommend acceptance or rejection of work.

Provide positive and constructive feedback to the team.

So how is different from their role today?


15

Sample Team Structures


16

The Business Analyst

• During the iteration, the BA works on making sure the requirements and test cases are understood by developers for all stories. (Not just documented well!)

• They chase down answers to questions, help facilitate meetings and help make sure each developer has what they need.

• 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.

• A strong BA is usually the ScrumMaster‟s right hand person and their backup.

BA Role ..

• The BA is also in charge of making sure the backlog and project workbook is updated.

• Make their artifacts and documentation easy to read and find by people who need them.

• Makes sure the right SMEs are attending any team sessions that need them.

• A strong BA is the „glue‟ that helps tie everything together during the iteration.

• Results driven, focused, energetic, positive, collaborative, strong facilitator, willing to do „whatever it takes‟ to help the team succeed. These are the qualities of a strong agile BA.


18

The Agile Lifecycle – Big Picture

Release Planning

• What are the top priority items we need to deliver in this release?

• How Big/Small is each one? What is the dependency between them?

• How much can the team handle each iteration? Pencil in the next several iterations.

• What are our „Conditions of Satisfaction‟ for this release? When are we „Done‟?


20

Release Planning


21

Product Owner

thinks of New Idea

Product Backlog

Sprint Backlog

Features/Stories Small Stories

Each story is broken down into tasks. Each team member signs up for tasks and provides estimates of effort.

Tasks

Spri

nt

1Sp

rin

t 2

Spri

nt

3Sp

rin

t 4

Spri

nt

N

Each Iteration is 1 – 4 weeks in length. Multiple iterations make up a Release.


22

The Backlog Hierarchy

Business Domain

Theme/Feature/Epic

Story1 Story2

Feature2

Story3


23

Sample Backlog


24

Agile Requirements

• Stories: Light weight description of a small valuable business deliverable.

• Details of a story can be extracted using:– Acceptance Test Cases

– Business Rules

– Business Process /Activity Diagrams

– User Interface Prototypes

• All documentation must be valuable and actually consumed by someone!

• More on this in August!


25

Release Planning Meetings

• Here are some common meetings during

Release Planning:

– Resource Planning Meeting ( who do we

need?)

– Story Identification, Breakdown and

Prioritization

– Story sizing and dependency.

– Building the Release Plan


26

Iteration Pre-Planning

• The BA along with the product owner should spend some time each iteration pre-planning for the next iteration. This involves:

– Identifying the top priority stories the team needs to work on next.

– Identifying and writing acceptance test cases for each.

– Identifying any upfront design or testing work that needs to be done.

– Developing any UI sketches or business activity diagrams.


27

Iteration Planning

• Half day or full day meeting to answer the

following:

• What are the top stories we need to get done this

iteration?

• Discuss how will we know when each story is „Done‟,

review and contribute to the acceptance test cases?

• What tasks do we need to get each story done?

• Who will signup, commit and provide an ETA for each

task?


28

Sample Iteration Plan


29

Story Points

• We simply use relative complexity buckets

to size each story.

Copyright(c) Sally Elatta 2009

www.AgileTransformation.com30

Smallest

20+

Small Medium Med-large Large Very Large EPIC!

How many stories a team gets ‘Done’ each iteration is their Velocity

BA Iteration Check List

Help setup task board

Get acceptance test cases to each developer

Update workbook & backlog

Pre-Planning for next iteration

Test data setup coordination

Coordinate user testing

Coordinate final demo and retrospective

Glue everything together!


31

Daily Tracking

• What did you do yesterday?

• What will you do today?

• Any Impediments?


32

Iteration Review

• Product owner and team show off what the team got

done in the last iteration and discuss impediments.

• Get feedback from other users

and stakeholders and discuss

plan for next iteration.


33

Iteration Retrospective


34

What Worked Well?

• Impediments were removed quickly

• Team collaborated well to solve problems.

• Business users attended standups

What Needs Improvement?

• Prioritize stories before team meeting

• Identify acceptance tests before meeting

• Begin using TDD

New BA Skills Needed

• Facilitation and Controlling Meetings.

• Flexibility, being a Generalizing Specialist.

• Requirements Gathering Skills are different.

• Working on a cross functional team.

• Measurement of Success is based on team

delivery of actual points not documentation

signoffs.

• What else?


35

New Skills Are Needed!

• Business: Leadership, Teamwork and Collaboration

Ability to define stories and user test cases

Ability to perform acceptance testing

Ability to truly prioritize what is needed now and

what provides value.

Better understanding of the technical world

Time management and commitment.

Support and stay positive

Understand ROI and when we‟re „Done‟


36

New Skills Are Needed!

• IT: Facilitation, Leadership, Teamwork and Collaboration.

Ability to breakdown stories into small manageable

tasks.

Ability to focus on getting stories completed

Ability to work and collaborate within the IT department

(cross functional).

Communication, synchronization between multiple

teams.

Focus more on business value (ROI) than technical

implementation.


37

So Why is Agile Being Adopted?

Seeing working software each demo.

High visibility into project progress.

Early and continuous customer feedback results in

delivery of software they want and will use.

Product Owner is empowered to make decisions.

Customer can get what has been completed on the

release date if they choose.

Agile change management is more welcoming to

change than traditional change management.

Highest Priority Items delivered first.


38


39

How Agile Can Fail!

No top level management commitment and support

No customer commitment to collaboration

Inexperienced Scrum Masters leading the effort

Reverting to form due to no agile evangelist

Ineffective or no release planning

Skipping Iteration 0

Ineffective use of retrospectives (or no

retrospectives)

A culture not open to change

Not comfortable dealing with what Agile exposes

A culture of command and control

How We Can Help

Training

• Executive and Business Overview of Agile/Lean

• Real World Agile and Scrum team training + Project Jump Start

• Effective Facilitation & Requirements Gathering

• Servant Leadership

• SOA

• … More!

Coaching & Consulting

• Troubled Project Assessment & Recovery

• Agile Project Initiation and Planning

• End to End Project Execution

• Organizational Assessments

• Process Improvement Roadmap Execution

http://agiletransformation.com/index.php/training/agile-training/real-world-agile-and-scrum/



http://agiletransformation.com/index.php/training/agile-training/mastering-the-art-of-facilitation/

http://agiletransformation.com/index.php/training/agile-training/effective-requirements-gathering/

http://agiletransformation.com/index.php/training/agile-training/becoming-a-servant-leader/

http://agiletransformation.com/index.php/training/technical-transformation/

• My Article: http://tinyurl.com/6h5mam

• Watch the 10 minute video intro to

Scrum: http://tinyurl.com/5py7ct

• www.AgileAlliance.org

• Questions? [email protected]

Resources

42

http://tinyurl.com/6h5mam

http://tinyurl.com/5py7ct

http://tinyurl.com/5py7ct

http://www.youtube.com/watch?v=Q5k7a9YEoUI

http://www.youtube.com/watch?v=Q5k7a9YEoUI

Technology

Overview of Agile for Business Analysts