overview of agile for business analysts
TRANSCRIPT
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.
• 402 212-3211
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com2
• 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
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
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
7
Project Management Principles
(Release Planning, Sprint and Iteration Planning, Daily Scrum,
Sprint Demo and Retrospective ..etc)
Engineering Principles(TDD, Continuous Integration,
Refactoring ..etc)
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
8
Agile Characteristics Product Backlog
Test Driven Development Business / IT as One Team9
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
Committed:
– Scrum Master
– Product Owner
– The Team
Interested:
– Stakeholders
– Users
Agile/Scrum Roles
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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?
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
15
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
18
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‟?
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
20
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
22
The Backlog Hierarchy
Business Domain
Theme/Feature/Epic
Story1 Story2
Feature2
Story3
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
23
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!
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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?
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
28
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!
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
31
Daily Tracking
• What did you do yesterday?
• What will you do today?
• Any Impediments?
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
33
Iteration Retrospective
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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?
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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‟
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
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.
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com
38
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
• 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