SCGMIS Agile Business Analysis Workshop July 2014

1© Life Cycle Engineering 2014© Life Cycle Engineering 2014

The Business Analyst in an Agile Environment Presented by Justin Petite for SCGMIS

2© Life Cycle Engineering 2014

• 12 years in a number of roles supporting software and the SDLC

• Past 4+ years adapting and applying Agile and Scrum to SPAWAR projects

• PMI – Agile Certified Practitioner

• Scrum Alliance Certified Scrum Master

• Scrum Alliance Certified Scrum Professional

jpetite@lce.com

@JustinPetite

JUSTIN PETITE

STARTING LINEUP• 5 minutes• Confidence in your understanding of Agile• Without talking

AFFINITY ESTIMATION

• Visualize and create groups by relative scale

• Comparison by subjective measure

• Good for large groups, and large quantities

• Intended to be fast, and just precise enough to get started

More on this later…

OBJECTIVES

• Explore Agility, the Agile Manifesto, and Agile principles

• Understand how business analysis fits into the Agile environment

• Introduce personas and user stories

• Experience a variety of analysis tools and techniques used on Agile projects

System Requirements

Software Requirements

Analysis

Design

Operations

“WATERFALL”

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding 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.

An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.

Scott Ambler

http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

AGILITY

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment

Agility is the ability to balance flexibility and stability

Jim Highsmith

Agile Project Management (2nd Edition, 2010)

WHY AGILITY

• Need to more effectively respond to change

– Organizational needs

– Market demands

– Threats and opportunities

• Manage evolutionary change to products, processes, and culture

• Frequently and incrementally deliver value to reach a desired goal or outcome

BENEFITS

• Greater responsiveness to changing priorities• Measured increase in productivity• Lower costs• Managed risk through greater visibility• Increased customer satisfaction• Better overall quality• Improved team morale

VALUE IN “WATERFALL”cu

AGILE VALUE PROPOSITION Acu

AGILE VALUE PROPOSITION Bcu

AGILITY

AGILE PRINCIPLES1. Our highest priority is to

satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

AGILE PRINCIPLES7. Working software is

the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10.Simplicity—the art of maximizing the amount of work not done—is essential.

11.The best architectures, requirements, and designs emerge from self-organizing teams.

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

AGILE METHODOLOGIES• Extreme Programming (XP)• Scrum• Kanban• Scrum-ban• Disciplined Agile Delivery (DAD)• Scaled Agile Framework (SAFe)• Dynamic Systems Development Method (DSDM)• Feature Driven Development (FDD)• Lean software development

AGILE PRACTICES• Cross-functional teams• Timeboxed iterations• Story-driven modelling• Backlogs (product, release, sprint)• Acceptance Test Driven Development (ATDD)• Test Driven Development (TDD)• Continuous integration and deployment• Pair programming• Information radiators• And many, many others

Accredited to Michael Sahota & Olaf Lewitz

Value(Releasable Product)

Quality(Reliable, Adaptable Product)

Constraints(Scope, Cost, Schedule)

AGILE TRIANGLE

Jim Highsmith

AGILE METHODS DO:

• Position us to be more responsive to changing priorities

• Allow better predictability of output for the foreseeable time horizon

• Improve accountability

• Make priorities and risk calculations more transparent

AGILE METHODS DON'T

• Make engineers write more lines of code per day or designers create output faster

• Preclude the need to make good organizational decisions about product, priorities, and customer needs

• Allow the rest of the organization to assume they think they know what lies months ahead

AGILE MYTHS• “Agile is the silver bullet for our organization!”

• “Agile doesn’t scale, so it can’t work for our organization!”

• “No more documentation or deadlines!”

• “Since we don’t do things upfront, we have no design and poor architecture!”

• “With so much rework going on, nothing new, and innovative gets worked on!”

• “Agile makes us faster!”

ORGANIZATIONAL AGILITY• More than just “doing Agile”• Discipline of managed change through continuous

inspection, evaluation, and adaptation• Tailored to the organization• Leverages Agile methods appropriately at each level:

– Individual– Team– Project– Program/Portfolio– Executive

THE AGILE BUSINESS ANALYST• Analysis still essential to software development,

regardless of project size, complexity, or methodology

• Analysis is still about asking the right questions

• Vital to the agile requirements decomposition paradigm

• Has an immediate impact on development

• Plays an integral role on the development team

ITERATIVE & INCREMENTAL

ITERATIVE & INCREMENTAL“Incrementing” builds a finished piece

Assumes the customer has a fully formed idea

of what they need

Jeff Patton - 2008http://www.agileproductdesign.com/blog/dont_know_what_i_want.html

ITERATIVE & INCREMENTAL

Jeff Patton - 2008http://www.agileproductdesign.com/blog/dont_know_what_i_want.html

“Iterating” builds something imperfect to validate and refine

Iterating allows for less developed ideas to

evolve and be refined

SCRUM• Framework:

– Defined Roles– Ritual Meetings– Artifacts– Terminology

• Emphasis:– Value– Delivery– Open communication– Team self-organization– Stakeholder Participation

SCRUM TIMEBOXES

• Release Planning• Sprint Planning• The Sprint

• Daily Scrum• Sprint Review & Demo• Sprint Retrospective

SCRUM ROLES

• Scrum Master– Lead, promote, facilitate, organize, and coach Scrum– Remove impediments for the team

• Product Owner– Own, manage, and communicate the Product Backlog– Advocate for the customer

• Scrum Team– Turn work from the backlog into a “potentially

shippable” increment of working software

ANALYST PATTERNS

http://www.romanpichler.com/blog/business-analysts-in-scrum/

ANALYST PATTERNS

ANALYST ANTI-PATTERN

RESPONSIBILITIES

Product VisionProduct Backlog

Guidance to Scrum Team

Stakeholder Expectations

PRODUCT OWNER

5 LEVELS OF AGILE PLANNING

Vision

Roadmap

Release

Sprint

Suggested Time box*

Outcome

Annual Vision

Semi-Annual Roadmap

QuarterlyRelease Backlog

2-4 weeksSprint

Backlog

15 mins daily “3 Questions”

PRODUCT VISION

The product vision is a high level statement

that provides the team with a shared

understanding of the what the end product

will look like.

PRODUCT VISION

Bill Shakelford: ‘Design the box’

Front of the box• Product Name• Graphic/logo• 3-4 key selling points

Back of box• Description of key features• Screens/mockups

Spine• System requirements

ELEVATOR PITCH

FOR (target customer)

WHO (statement of need)

THE (product name) is a (product category)

THAT (product key benefit, compelling reason to buy, problem being solved, etc.)

UNLIKE (primary competing alternative)

OUR PRODUCT (final statement of key differentiation)

Geoffrey Moore’s “Elevator Pitch”, Crossing the Chasm (1991)

AGILE PRODUCT CHARTER

• Mission: The “Why”, higher purpose, or the reason for the project’s existence.

• Vision: the “What” of the project stating what will be done in the project to achieve its higher purpose.

• Success Criteria: The success criteria are management tests that describe effects outside of the solution itself – Defines “Done”

AGILE PROJECT CHARTER

• 1 page (A3)• High level, but specific• Eliminate boilerplate• Aligned with stakeholder

Shared understanding of the charter is critical to enabling team members to collaborate effectively on large, enterprise projects

TARGET PRACTICE• 5 Minutes• Pick a product• Try a method

– Product Box– Elevator Statement– Charter (A3)– What else works for you?

Successful vision defines at a high level:

User – Opportunity – Critical features

Other context specific objectives and success factors

ROADMAP

• Connects the Product Vision to the execution plan• Provides the team with visibility, incentive, and focus• Not a commitment … a visualization of the plan

July Aug Sep Oct Nov

Security

User Admin

Payments

User Admin

Product AdminFulfillment

Security

BIG ROCKS

Grouping like features can be helpful for planning

These are often referred to as Themes or Epics

Security

Login with username/password

Password Reset

SSL 3.0

User Admin

User account DB

Update user info

Register User

Payment

Credit Card

Auto draft

PayPal Integration

ROADMAP

CHART YOUR COURSE

• 10 minutes

• Brainstorm how to deliver value early

• Come up with some high level themes

• Roughly prioritize

• 6 – 9 month horizon

PERSONAS• A fictional character based on role, and real

qualitative understanding of your user base

• Emphasize the user-centric approach and promote empathy for the user and customer

Picture and Name Details Goals or

Solution

Choose a picture and a name that are representative, and that allow you to develop sympathy for the persona

Relevant characteristics and behaviors:Demographics, job, lifestyle, spare time activities, attitudes, common tasks, etc.

Why would this specific persona want to buy or use this product?What problems are solved for this persona?What benefits are this persona seeking?

TIPS FOR USING PERSONAS• Start with quick and good enough - adapt over time

• Distinguish user personas from customer personas

• Choose a primary persona

• Make personas believable

• Stay focused and precise – problems and benefits

• Keep the personas visible

• Connect personas to user stories

INTRODUCE YOUR USERS

• 5 minutes

• Come up with 2-3 user personas for your product

• Tie user’s problem to your product’s solution

• Ensure each user has a role

TELL A STORY

USER STORY

• Simple and concise statement of requirement from a user perspective

• Originated in Extreme Programming (XP)

• Ron Jeffries: 3 C’s

– Card

– Conversation

– Confirmation

THOUGHT TEMPLATE

A conversation with the stakeholder:– “As a” specific user or persona– “I want” need, feature, or functionality– “So (that)” purpose and value of delivery

ACCEPTANCE CRITERIA

• Flip the card over to record expectations:

– User– Customer– Product Owner– Team

How has the customer defined success for this story?

INVEST

Independent

• Can ideally stand alone as a working product increment

• Avoids dependencies with other stories whenever possible

INVEST

Negotiable

• Stories are concepts not contracts

• Can and should be revised or rewritten up until they are planned in a sprint

INVEST

Valuable

• Should deliver value to the end user, customers, and/or stakeholders

• Why else would a story matter?

INVEST

Estimable

• The story provides the Team with enough information to approximate size

• By understanding size, we can then plan

INVEST

Sized appropriately (Small)

• Ideally can be completed in one iteration

• Small for near-term work

• Larger for work further out is ok, realizing further decomposition will be needed later

INVEST

Testable

• Acceptance criteria establishes common expectations across team members and stakeholders

• Critical to understand not just what will be tested, but also how it will be tested

SCGMIS Agile Business Analysis Workshop July 2014

Business

Workshop - prev.testwarez.plprev.testwarez.pl/.../uploads/2014/10/testwarez_Workshop-Agile-Test… · Agile Testing Workshop . Tilo Linz, imbus AG ... Agile Testing Folie 11 von 20

Agile workshop FACENSA

Agile Earned Value Management Workshop)

Agile Product Development Workshop

Workshop Agile Testing - CTQB...Workshop Agile Testing Introduction, ISTQB and CTQB What is Agile (Testing)? Problems and Challenges Agile Testing Practices Improve IT Services B.V

T systems - agile workshop 0. session

Agile lean workshop

Analysis With an Agile Mindset Workshop

Agile estimation techniques workshop

Growing trust workshop. Agile india 2015

Agile Engineering for Managers Workshop

21 Scott Ambler - Agile Data Workshop

Agile training workshop

Agile project inception workshop

CukeUp 2016 Agile Product Planning Workshop

PM Connect - Agile Workshop

Agile Scrum Workshop, Singapore

Agile Coaching Workshop

Agile Workshop: Handling Changing Requirements

Agile organization design workshop