slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Project Management PowerPoint Presentation
Download Presentation
Agile Project Management

Loading in 2 Seconds...

play fullscreen
1 / 190

Agile Project Management - PowerPoint PPT Presentation


  • 121 Views
  • Uploaded on

L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n. Agile Project Management. L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n. Pollyanna Pixton Founder, Accelinnova President, Evolutionary Systems Director Institute of Collaborative Leadership.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Agile Project Management' - duer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n

Pollyanna Pixton

Founder, Accelinnova

President, Evolutionary Systems

Director Institute of Collaborative Leadership

agenda
Agenda
  • What is Agile
  • Agile Methods
  • Scrum Deep Dive
  • Estimating and Planning
  • Getting Started
  • Leading Agile
project methods
Project Methods
  • Waterfall:
    • Function Definition, Design, Build, Check

Functions

Design

Build

  • New Methods:
    • Single Cycle Review and Adjust
    • Spiral: Multiple Cycles of Waterfall
    • Agile: Adapt As You Go: Short Iterations

Check

Done

what is agile
What is Agile?

From recognition and acceptance of increasing levels of unpredictability in our turbulent economy

  • A chaordic perspective
  • Collaborative values and principles
  • Barely sufficient methodology

- Jim Highsmith

agile encourages mid c ourse c orrections
Agile Encourages Mid Course Corrections

Zone of success

Planned Completion

Increasing Knowledge

Planned Path

Start

Actual Path

As Knowledge increases Leaders use iterations to guide project towards enhanced goal

Actual Completion

8

business driven faster more rewarding
Business Driven – Faster & More Rewarding

Staged

Releases

Profit

Breakeven

Breakeven

Self-Funding

Single

Release

Cost

Software by Numbers by Mark Denne and Jane Cleland-Huang

Agile projects have a break-even point earlier in time than a traditional waterfall project for applications of the same size.

Agile projects are more flexible. Can be stopped or restructured without losing all value.

Investment

Time

slide12

uses continuous stakeholder feedback

principles

end users

partners

insiders

slide16
Agile Defined…

Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.

what is agile1
What is Agile?
  • A development process that conforms to the values and principles of the Agile Alliance(agilealliance.org)
  • Originally for software development
agile manifesto
Agile Manifesto

While there is value in the items on the right we value the items on the left more.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
agile overview
Agile Overview

Agile:

  • Iterative and Incremental to deliver working software
  • Light-Weight
  • Meets Changing Needs of Stakeholders
  • Highly Collaborative: Involves Customers
  • Minimizes Documentation
  • Test First
light weight
Light Weight
  • Utilize only practices that make sense for the project and environment
  • “Barely sufficient” artifacts, methodology, and documentation
  • “Appropriate” vs “Best Practices”
practice excellence
Practice Excellence
  • Requires self discipline to improved quality
  • Relies on the team to practice technical excellence instead of imposing discipline
  • Adopt technical practices that support the other practices such as:
    • Continuous Integration
    • Test Driven Development
    • Refactoring
reflect and adapt
Reflect and Adapt
  • Learn from past to improve performance
  • Retrospectives after each iteration
  • Harness change for improved efficiency
  • Multi-Horizon planning allows adaptation
key characteristics of successful agile projects
Key Characteristics of Successful Agile Projects
  • Short, Stable, Time-Boxed Iterations
  • Stakeholder Feedback
  • Self-Directed Teams
  • Sustainable Pace
the process pendulum
The Process Pendulum

Code and Fix

Agile

Waterfall

No Process

Empirical

Prescriptive

  • Empirical
  • Frequent inspection
  • Collaboration
  • Adaptive responses
  • Prescriptive
  • Defined set of steps to follow
  • Plan the work, work the plan
  • Plan is assumed to be correct
project methods1
Project Methods
  • Envision
  • Iterate:
    • Plan
    • Implement
    • Done?
    • Adapt
  • Complete

Project Definition and Iterations

Planning

Review and Adjust

Implement

NO

Done?

YES

Completed Deliverables

agile cycles
Agile Cycles

Iteration Planning

Vision

Iterations Plan

Iteration Plan

Review / Adapt

Planning

Develop

High Level Planning

Detailed Planning

how does agile work
How Does Agile Work?

“Requirements” called features, defined using user stories: As a <user/role> …

I want to <goal> …

so that <value>.

agile process
Agile ‘Process’
  • User stories listed in a backlog.
  • Backlog prioritized based on value.
  • Highest priorities estimated and grouped into an iteration (sprint), two weeks long.
  • At end of iteration, ask if enough value to go to market?
  • Add any new user stories to backlog and reprioritize and select next iteration/sprint.
agile process1
Agile ‘Process’
  • Test cases are written first, before anything is developed
  • Go/no-go decisions reached early and often
agile must be disciplined
Agile MUST be Disciplined

Agile development necessitates greater discipline than traditional methods.

“Quality” and “Consumability” must be real, not platitudes.

slide33
“It is a bad plan that admits to no modifications.”-- Publius Syrus (ca. 42 BCE)

Project Management

slide35
Agile Defined…

Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.

references
References
  • What Is Agile Software Development? Jim Highsmith, CrossTalk, the Journal of Defense Software Engineering
  • The New Methodology, Martin Fowler http://martinfowler.com/articles
  • http://www.agilealliance.com/articles
  • Why Agile (video) http://www.universite-du-si.com/fr/conferences/6/sessions/909
user stories
User Stories

Your

Questions?

project management
Project Management
  • Remove Obstacles

AgileMethodologies

agile methods
Agile Methods
  • eXtreme Programming, XP(Kent Beck, Ron Jeffries, Ward Cunningham)
  • Scrum(Jeff Sutherland, Ken Schwaber, Mike Beedle)
  • Feature Driven Development, FDD(Peter Coad, Jeff DeLuca)
  • Crystal Methods (Alistair Cockburn)
  • Dynamic Systems Development Method, DSDM (DSDM Consortium)
  • Lean Development (Bob Charette, Mary and Tom Poppendieck)
agile overview1
Agile Overview

“Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries, XP Thought Leader

xp values and principles
XP Values and Principles
  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Quality Work
xp practices
XP Practices

The Planning Game

Small Releases

Metaphor

Simple Design

Refactoring

Test-First Development

xp practices1
XP Practices

Pair Programming

Collective Ownership

Continuous Integration

Sustainable Pace

On Site Customer

Coding Standards

xp roles
XP Roles
  • The Customer

Sets project goals and makes business decisions

  • The Developer

Turn customer stories into working code

  • The Tracker

Keeps track of any metrics used by team

  • The Coach

Guides and mentors team

scrum roles
Scrum Roles
  • Scrum Team
  • Scrum Master
    • Carries water and moves boulders
  • Product Owner
    • Responsible for maintaining product backlog
scrum control points
Scrum Control Points

Meetings:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review(retrospectives and demo)
feature driven development fdd
Feature Driven Development (FDD)

Model-driven short-iteration process that consists of five basic activities:

Develop

Model

Build

Feature

List

Plan By

Feature

Design by

Feature

Build By

Feature

Deploy

- Jeff deLuca, 1997

fdd focus
FDD Focus
  • (Object) Modeling centric
  • Client centric
  • Architecture centric
  • Pragmatic
  • Functional decomposition
    • Subject Area
    • Business Activity
    • Business Activity Step
fdd roles
FDD Roles
  • Chief Programmers

Team lead, mentor, developer

  • Class owner

Developer with responsibility for a class

  • Feature teams

Temporary groups of developers formed around classes

crystal clear
Crystal Clear

Frequent Delivery

Reflective Improvement

Osmotic Communication

Personal Safety

Focus

Easy Access to Expert Users

Automated Tests

Configuration Management

Frequent Integration

crystal clear1
Crystal Clear

“The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.”

- Alistair Cockburn

crystal clear2
Crystal Clear

“Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve.”

- Alistair Cockburn

crystal clear roles
Crystal Clear Roles
  • Sponsor: Allocates money for the project
  • Expert User
  • Lead Designer
    • Lead Technical person, mentors less experienced team members
  • Designer-Programmer
    • Each person designs and programs
slide56
DSDM
  • Active user involvement
  • Teams empowered to make decisions
  • Frequent delivery of products
  • Fitness for business purpose
  • Iterative and incremental delivery
  • All changes reversible
  • Testing throughout lifecycle
  • Collaboration with all stakeholders
agile method s focus
Agile Method’s Focus

Methodology

DSDM

Project Management

Engineering

Scrum

Crystal

FDD

XP

Structure

DSDM

Unstructured

Structured

Crystal

FDD

Scrum

XP

lean manufacturing
Lean Manufacturing
  • Optimizing production through removal of waste and improving flow
  • A process management philosophy based on Toyota Production System (TPS)
  • Focus effort on producing value-added features
  • Just in time delivery
lean software development
Lean Software Development
  • Everything not adding value to customer is waste includes:
    • Unnecessary code and features
    • Delay in development
    • Unclear requirements
    • Bureaucracy
    • Slow internal communications
  • By Mary and Tom Poppendieck
project management1
Project Management

Agile Project Management:

  • The PM is the person who facilitates the team's work, removes obstacles, manages risks, and explains to management what is going on. Good PMs are on the side of the team, because that's how the product gets delivered. The ScrumMaster facilitates the team's process and removes obstacles for the team.
project management2
Project Management

Agile Project Management:

  • Following the values and principles of the Declaration of Interdependence (DOI)
  • Written by the founders of the Agile Project Leadership Network (apln.org)
declaration of interdependence
Declaration of Interdependence
  • Continuous flow of value
  • Engage customers
  • Create an environment where individuals can make a difference
  • Expect uncertainty and manage for it
  • Context specific strategies, processes, and practices
  • Group accountability
slide65

Project Statistics

Standish Group Study, reported by CEO Jim Johnson, CIO.com, ‘How to Spot a Failing Project’

project statistics
Project Statistics

Improvements

Due To Better:

  • Tools
  • Project Managers
  • Adaptive Methods
    • Breaking projects into small chunks
    • Delivering pieces faster for user feedback
slide67

Never or Rarely Used: 64%

Always or Often Used: 20%

Rarely

19%

Sometimes

16%

Often

13%

Never

45%

Always

7%

Standish Group Study, reported by CEO Jim Johnson, XP2002

failures
Failures

Main Reasons For Project Failure :

  • Lack of end user involvement
  • Poor requirements
  • Unrealistic schedules
  • Inadequate change control
  • Lack of testing
  • Inflexible processes
success factors
Success Factors
  • User involvement
  • Management support
  • Clear vision & objectives
  • Proper planning
  • Realistic expectations
  • Smaller milestones
  • Competent staff
  • Ownership
challenges
Challenges
  • Deliver the rightproduct
  • Meet customer’s changing needs
  • Deliver to rapidly moving market windows
  • Innovate on both sides of your business model
  • Get more done by doing less
  • Lead in the marketplace
companies must
Companies Must…
  • Deliver Business Value
  • Increase Productivity
  • Lead Change
  • Find Solutions
  • Innovate
project management3
Project Management
  • Remove Obstacles

AgileMethodologiesSummary

agile methods summary
Agile Methods Summary
  • eXtreme Programming, XP
  • Scrum
  • Feature Driven Development, FDD
  • Crystal Methods
  • Dynamic Systems Development Method, DSDM
  • Lean Development
user stories1
User Stories

Your

Questions?

scrum on a page
Scrum on a Page

Roles

Product Owner

ScrumMaster

Stakeholders

Team

Product

Backlog

Release

Backlog

Sprint

Backlog

Blocks

List

Information Radiator

Artifacts

Release Plan

Meeting

Sprint Plan

Meeting

Daily

Scrum

Sprint Review

Meeting

Meetings

Concept inspired by William Wake’s “Scrum on a Page,” http://xp123.com/xplor/xp0507/index.shtml

stakeholders
Stakeholders

Anyone that can give input to the business objectives of the product.

slide80

The customer is always moving, changing, and if you’re not out there all the time trying to understand the functional and emotional needs of consumers, your design will simply fall flat.

- Matthew May

slide81

Outside-in development is a set of principles that focus teams on developing software which helps stakeholders be successful in their business.

Problem: Solutions don’t work as imagined.

Cause: The facts aren’t clearly understood.

Solution: Learn to see.

Goal: Get inside the [stakeholder’s] mind.

Understanding Your Stakeholders

Defining Success in Your Stakeholders’ Term

Aligning with stakeholder goals

Making Products Consumable

Understanding Organizational Context

Outside-In Software Development

i can t imagine a world without
I can’t imagine a world without

Your product

Not only could I

imagine a world

without it, I long

For it

Without it, our

business would

suffer, and I

would feel a

sense of

personal loss

It usually does

what we want,

if painfully at

times

You know you’re lean when: customers pull compelling value from you effortlessly.

product owner
Product Owner
  • Prioritizes backlog in collaboration with …
scrum master
Scrum Master
  • Removes the barriers between development and the customer so the customer directly drives development
  • Facilitates creativity and empowerment
  • Improving the productivity of the development team in any way possible
  • Improving the engineering practices and tools so each sprint is ready to deploy
scrum master1
Scrum Master
  • Is not the project manager
      • Team manages itself
  • Doesn’t have authority over the team
      • Team makes decisions
  • Always asks the question:

“How are the Product Owner and Team doing?”

  • Challenges the organization, key-role in the change
      • However, a dead scrum master is a useless scrum master
slide86
Team

Teams

  • Add self organizing and ownership bits here.
unleashing innovation
Unleashing Innovation

Collaboration Process

Exercise

quick exercise a
Quick Exercise (A)
  • Form pairs
  • Assign one as boss, the other as worker
  • The boss can give the following commands: Go, Stop, Right, Left, Faster, Slower
  • The worker must follow the boss’s commands
  • Goal: 60 steps in two minutes
  • The boss can command the worker but not touch the worker
quick exercise b
Quick Exercise (B)
  • Everyone is a worker and responsible for figuring out how to proceed during the exercise
  • Goal: 60 steps in two minutes
self directed or self organizing teams
“Self-directed” or “Self organizing” Teams
  • The concepts of leadership, management, and team involvement are prospectively very different
  • Encouraging a collaborative environment
  • All roles support one another
the whole team concept
The “Whole Team” Concept

Coders/programmers

ID/Writers

Product Champion

Architect

Designer

Product Owner

Other Roles

Project Managers

Testers

create a trusting environment
Create a Trusting Environment

When you're in a ‘trusted’ environment, teams tend to innovate better, more quickly and overall transaction costs are much lower.

Sue McKinney

VP MSM Development

Pitney Bowes

trust ownership model
Trust/Ownership Model

Trust

Failure

No One Cares

Energy & Innovation

Team Trusted

Team Accountable

Leader Freed

How do weget here?

Leadership

& Business Process

Command & Control

Team Does as Instructed

No Ownership

Leader / Process

is Bottleneck

Conflict

Team Demotivated

Mired in Bureaucracy

& Wasted Effort

Control

Team/Individual Ownership

Low

High

what does a trust environment feel like
What Does a Trust Environment Feel Like?

Leader’s View

  • The team won't let me down
  • The team understands what we need
  • They will do the right thing
  • They will tell me if they need help
what does a trust environment feel like1
What Does a Trust Environment Feel Like?

Individual within the Team

  • We understand the vision and the need
  • We are jointly committed to meeting our goals
  • We stand or fall together
  • We have Ownership
self directed teams is this lunacy
Self-directed teams: Is this lunacy?

Two principles supporting the Agile Manifesto:

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
definitions1
Definitions

RolesSummary

roles in a nut shell
Roles in a Nut Shell
  • Stakeholders: gives input as to the product business objectives
  • Product owner: responsible for the business value of the project
  • ScrumMaster: ensures that the team is functional and productive
  • Team: self-organizes to get the work done
product backlog
Product Backlog
  • The current view of the requirements
  • Consists of Epic User Stories
  • Prioritised by the Product Owner in collaboration with Stakeholders
  • Prioritized based on Business Value and Risk
release backlog
Release Backlog
  • Each Release has a theme
  • Release Backlog contains the User Stories for that release
  • Made up of User Stories (broken down Epic User Stories)
sprint backlog
Sprint Backlog
  • Each Sprint has a goal
  • Team agrees on goal and commits to it
  • User Stories for the Sprint
blocks list
Blocks List
  • Internal – Actions within the team
  • External – Actions beyond the team
  • Updated by the Scrum Master
  • Scrum Master resolves them with team
information radiator
Information Radiator
  • Visual representation of progress
  • Display of:
    • Work Planned (Product, Release and Sprint)
    • Work in Progress
    • Work Done
    • User Stories to mitigate risk
    • User Stories to gather information to make future decisions
burndown chart
Burndown Chart

Part of the Information Radiator

artifacts summary
Artifacts Summary
  • Product backlog: prioritized list of desired project outcomes/features (epic user stories)
  • Release Backlog: prioritized list of user stories for the release
  • Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint
  • Information Radiator: at-a-glance look at the work progress
slide110

Meetings

  • Leadership Influence
sprint planning meeting
Sprint Planning Meeting
  • At the beginning of a new Sprint
  • Chaired by the Scrum Master
  • Attended by all including Key Stakeholders
  • Update the Product Backlog with new requirements
  • Select highest priority items in the backlog based on Business Value
  • Define the Sprint Goal
daily scrums
Daily Scrums
  • Daily 15 minute status meeting
  • Same place and time every day
  • Chaired by Scrum Master
  • Attended by entire sprint team
  • Others can attend
  • Chickens and pigs (only the deliverers speak)
daily scrums1
Daily Scrums

Each team member answers:

  • What did you do yesterday?
  • What are you doing today?
  • What are your blocking issues?

No problem solving!

Leave after 15 minutes!

daily scrum
Daily Scrum

Records

  • Sprint Backlog up to date
  • Scrum Master updates the blocks list
sprint review meeting
Sprint Review Meeting
  • Held the last day of the sprint
  • Attended by team
  • Team demos “done” user stories to stakeholders
        • Requests feedback
  • Team holds retrospective
        • Updates the process for the next sprint
demonstration
Demonstration
  • Only DONE working user stories.
  • Ask for attendance from the following for the first 4 iterations as numbered:
    • Executive
    • Internal users
    • Stakeholders
    • Customers
team defines of done
Team Defines of “Done”

Consider:

  • No showstoppers
  • All errors that the team has not agreed to are removed
  • Code is unit tested, function tested, system tested, performance tested, tested end-to-end
  • A meaningful stakeholder review has been conducted
team defines of done1
Team Defines of “Done”

Can this really be done? This puts a high premium on:

  • Valuable, maintained, nested automation
  • Appropriate coverage (e.g. 80%)
  • True test-driven development
  • Avoiding technical debt
  • Continuous integration
  • Really understanding what quality looks like
example1
Example

Jeff Sutherland (co-creator of Scrum), said while @ PatientKeeper:

“It took us four years to get done, done, done, done.”

Patientkeeper provides safety critical patient management software

example2
Example

What does “Done”, “Done”, “Done” mean?

  • It is fully developed
  • It is fully tested
  • It has no Severity 1s or 2s
  • It has been deployed before a release in a client environment
example3
Example

They ship

  • A major release every 3 months
  • A minor release every month
  • And minor updates once a week

Consider the competitors, teams of 600-700 developers and they cannot achieve the work flow Patientkeeper does.

retrospective
Retrospective
  • Keep
  • Drop
  • Add

Keep? Drop? Add?

What surprised you?

slide124

MeetingsSummary

  • Leadership Influence
scrum meetings summary
Scrum Meetings Summary
  • Sprint planning: team and product owner choose work to deliver during a sprint
  • Daily scrum: team meets each day to share struggles and progress
  • Sprint reviews: team demonstrates what completed during the sprint
  • Sprint retrospectives: team discusses ways to improve product and process.
unleashing innovation1
Unleashing Innovation

Collaboration Process

Scrum Exercise

develop a brochure in a 3 day sprint
Develop a Brochure in a 3 day Sprint

Complete Sprint Planning Meeting -10min

  • Select at least 5 Product Backlog Items
  • Identify 2 to 3 Tasks per Item

Day 1

  • 8 minute day

Day 2

  • 2 minute Daily Scrum Meeting
  • 8 minute day

Day 3

  • 2minute Daily Scrum Meeting
  • 8 minute day

Demo & Reflection

00

06

10

08

07

09

05

04

03

02

01

02

00

08

07

06

05

04

03

01

00

02

01

08

07

06

05

04

03

02

01

00

00

02

01

02

03

04

01

06

07

08

05

00

scrum on a page1
Scrum on a Page

Roles

Product Owner

ScrumMaster

Stakeholders

Team

Product

Backlog

Release

Backlog

Sprint

Backlog

Blocks

List

Information Radiator

Artifacts

Release Plan

Meeting

Sprint Plan

Meeting

Daily

Scrum

Sprint Review

Meeting

Meetings

Concept inspired by William Wake’s “Scrum on a Page,” http://xp123.com/xplor/xp0507/index.shtml

scrum best practices
Scrum Best Practices
  • Test Driven Development
  • Pair testers and developers
  • Continuous Integration
references1
References
  • http://scrumalliance.org/pages/what_is_scrum
  • http://scrumalliance.org/pages/scrum_student_resources
  • The Elegant Solution, Matthew May
  • Outside-in Software Development, Carl Kessler and John Sweitzer
references2
References

Agile Project Management with Scrum, Ken Schwaber

  • Agile Software Development with Scrum, Ken Schwaber and Mike Beedle
scrum deep dive questions
Scrum Deep Dive - Questions

Scrum Deep Dive Questions?

leading agile
Leading Agile

User Stories

  • Collaboration Model
  • Collaboration Process
user stories overview
User Stories Overview
  • Basics
  • Creating
  • Refine
  • Flow
leading agile1
Leading Agile

User Story Basics

  • Collaboration Model
  • Collaboration Process
what is a user story
What is a User Story?

A concise, written description of a piece of functionality that will be valuable to a stakeholder.

As a <role>,

I can <goal>

so that <business value>

user story roles
User Story Roles

As a <role>, I want to <goal> so that I can <business value>

  • Avoid “the user” as different stakeholders have different needs
  • M. Cohn recommends using roles so that you do not “miss” stories
  • Teams can develop a set of user roles to help define relevant stories
user story goals
User Story Goals

As a <role>, I want to <goal> so that I can <business value>

  • Goal is “what the role can do”
    • Valuable to a stakeholder
    • Doesn't say “how”, but “what”
user story business value
User Story Business Value

As a <role>, I want to <goal>so that I can <business value>

  • Justifies the value of the story
    • Clarifies why a feature is useful
    • Can influence how a feature should function
    • Helps prioritize the story in the backlog
    • Can lead to other useful features that support the user’s goals
example4
Example

As an < astronaut >

I can < write easily while in Zero gravity >

So that < I can record key information that I might otherwise forget >

example5
Example

NASA specified and developed, at great expense, a ball point pen that Apollo astronauts could use in space where gravity would not make the ink flow. Russian cosmonauts used pencils.

Moral: specify what you want to achieve, not how to achieve it

exercise
Exercise
  • At your table, build three user stories
why use user stories
Why use User Stories?
  • Right size for planning, works for iterative development
  • Defer detail until you have the best understanding you are going to have about what you really need
  • Focus on user goals rather than feature attributes
why use user stories1
Why use User Stories?
  • Emphasize verbal rather than written communication
      • Potentially fixes issues with “vague requirements”
  • Comprehensible by both stakeholders and the development team
  • Stories support evolutionary development
where user stories help
Where User Stories Help

Value to Stakeholders

  • Stories target functionality valuable to stakeholders
  • Story demos each iteration engage stakeholders
where user stories help1
Where User Stories Help

Simplified Features

  • Stories enable light-weight requirements gathering, progressive discovery
  • Stories focus on feature essentials
where user stories help2
Where User Stories Help

Release Predictability

  • Stories by definition fit in time-boxed iteration
  • Stories that fail in an iteration provide early warning system
  • Cadence of story completion over multiple iterations will demonstrate release predictability
leading agile2
Leading Agile

Creating User Stories

  • Collaboration Model
  • Collaboration Process
release themes
Release Themes
  • Release themes are based on business objectives
  • A well known release theme is critical to team success
  • Themes should embody highest business value needs of the stakeholders and the product
release themes1
Release Themes
  • Focus on stakeholder success
  • Focus on product welfare: reduce technical debt, increase maintainability, etc.
  • Provide a common goal for the “whole team”
  • Prioritize and de-prioritize work
epic user stories
Epic User Stories

Epic User Stories capture stakeholder goals for release themes.

  • Epic User Stories fit into releases
  • Will not likely fit in an iteration
  • Team has an idea of how large the effort is
  • Product backlog contains Epic User Stories
  • Create Epic User Stories with Stakeholders
  • This is the product backlog.
creating user stories
Creating User Stories

Don’t focus only on the end-user role.Consider other stakeholder types as well.

creating epic user stories
Creating Epic User Stories

Insiders:

  • As a database administrator
  • I can back up a database
  • So that the data can be recovered if a failure occurs.
creating epic user stories1
Creating Epic User Stories

Insiders:

  • As a developer,
  • I know within 15 minutes whether the new code I checked in is integrated successfully with previous code
  • So that …

What is the business value for this user story?

creating epic user stories2
Creating Epic User Stories

Principals want time to value, return on investment:

  • As a principal,
  • I can have the software deployed and running in production less than one month after purchase,
  • So that ….

What is the business value for this user story?

creating epic user stories3
Creating Epic User Stories

Partners (business partners, support organizations...)

  • As a support engineer,
  • I can easily understand the levels of OS software used so that I can quickly reproduce reported failures,
  • So that ….

What is the business value for this user story?

unleashing innovation2
Unleashing Innovation

Collaboration Process

Exercise

exercise1
Exercise
  • At your table, pick a product
  • Create Release Themes
  • Create 2-3 Epic User Stories for the first/next 3 releases
user story team
User Story Team

Create a User Story Team, including (but not limited to):

  • Product Owner
  • Stakeholders
  • Scrum Master
  • Cross-disciplinary Representatives from the scrum team
    • Technical knowledge required
user story team1
User Story Team

Stakeholders on User Story Team

  • Represent each important stakeholder type:
    • Principles
    • End Users
    • Partners
    • Insiders
  • If real stakeholders are not available, assign stakeholder champions (team members)
  • Champions get to know the stakeholder, understand their requirements
user story team2
User Story Team

Refer to Mike Cohn’s book for details on how to form a user story team and gather epic stories.

user story team3
User Story Team
  • Keep team as small as possible… but not too small
  • Identify team champion to coordinate input
  • Agree on success factors for release
  • Use team to develop the first draft of user stories
  • Use appropriate team members to further re/define stories right before every iteration
leading agile3
Leading Agile

Refining User Stories

  • Collaboration Model
  • Collaboration Process
project management4
Project Management

Breaking stories into smaller stories

How Do We Deliver?

using user stories
Using User Stories
  • Break Epic User Stories into smaller User Stories
  • Break Epics for the next one (or two) releases
  • User Stories by definitionfit into an iteration
  • User Stories from the Release Backlog
  • Avoid user stories that are too small:
    • When documenting the story takes longer than implementing it
    • Bugs, user interface tweaks, etc.
user stories2
User Stories

Successful iterations have multiple small stories:

  • Smaller stories can be implemented & tested progressively throughout the iteration
  • Reduces the time between code and test
who sizes the stories
Who Sizes the Stories?

Cross-disciplined scrum team that will deliver the story

  • Stories are sized in "story points" – relative to one another
    • Based on the team’s skills
    • Based on the technology they will use
  • Use “Planning Poker” (next class module)
  • No two scrum teams will size the story the same
who sizes the stories1
Who Sizes the Stories?

What if you cannot size a story?

  • May need more domain knowledge, have more conversations
  • If technology is unknown, use architectural spikes
    • Short (time-bounded) iteration to learn “just enough” to proceed
user stories3
User Stories

Recommendation:

  • Do not maintain a hierarchy of stories under an epic
    • Easier to manage a flat list of user stories
  • Hierarchical stories overcomplicate the backlog
    • Hard to remove smaller stories
splitting on operational boundaries
Splitting on Operational Boundaries

First:

  • Basic User Interface
  • 50% of search fields
  • Parts of query builder that used those fields
  • Message “search found 297 matches”

Second:

  • Data display grid

Third:

  • Remaining search fields
  • Remainder of query builder

Search Screen

Fields

Query

Builder

Complex Data

Display Grid

Data-base

splitting into separate crud operations
Splitting into separate CRUD operations

As a technical marketing rep, I can add (create) an orderable part to the online catalog

As a technical marketing rep, I can view (read) the list of orderable parts in the online catalog

As a technical marketing rep, I can edit (update) an orderable part in the online catalog

As a technical marketing rep, I can remove (delete) orderable parts from the online catalog

remove cross cutting concerns
Remove Cross-Cutting Concerns

Consider creating two versions of the story: One that meets cross-cutting concerns and one that does not.

Cross-cutting concerns:

  • Security
  • Logging
  • Error handling
  • Etc.
attributes of a good user story
Attributes of a Good User Story

INVEST( From Mike Cohn)

exercise2
Exercise
  • Break your Epic User Stories for the first release into User Stories.
  • Do they all have the attributes of a good user story (INVEST)?
leading agile4
Leading Agile

User Stories Flow

  • Collaboration Model
  • Collaboration Process
flow the big picture
Flow: The Big Picture

Epics

Stories

Epics

Stories

Release

Planning

Trawl for

Requirements

Create/size

User

Stories

ReleaseBacklog

Stakeholder

Goals

Iteration Backlog

Select

High-priority

Stories

Reflect& Take Action

Time Boxed Iteration

Get Feedback

Refine Stories,

Plan Work

  • Scrum
  • Code, Doc & Test
  • Discuss Story Progress

Demo Working Code to Stakeholders

evolutionary feature design
Evolutionary Feature Design

Why not stick to well defined features documented in the beginning of the release?

  • Once users see a feature start to work,they better understand how they want to use the feature
  • Feature design & functionality will adapt to what becomes possible in the technology as you use it & learn about it
  • Release priorities, market forces, and stakeholder needs change throughout the life of the product
  • Team members learn from stakeholders as they go
evolutionary design how it can work
Evolutionary Design: How it can work

User Stories Summary

Map content released functionality iteratively

1: Input an address and see the location on a street map

2: Input two addresses and get directions between them

3: Change the route by dragging the route to other streets

If this feature was fully specified in the beginning, how would it look?

How would you specify alternate routes? Using current traffic? Listing the other roads to use?

Once you see the route, it seems obvious to want to drag it

Lessons? Evolutionary feature design worked

  • Get “enough” functionality out sooner
  • Discover what feature to add next based on feedback
user stories overview1
User Stories Overview
  • Basics
  • Creating
  • Refine
  • Flow
terms
Terms
  • Epic User Story
  • User Stories
  • Release Themes
  • Champions
  • Architecture Spikes
references3
References
  • Agile Project Planning: Writing Good User Stories: http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html
  • User Stories Applied, Mike Cohn
user stories4
User Stories

Your

Questions?

key characteristics of successful agile projects1
Key Characteristics of Successful Agile Projects
  • Short, Stable, Time-Boxed Iterations
  • Stakeholder Feedback
  • Self-Directed Teams
  • Sustainable Pace
project framework iteration plan
Project Framework - Iteration Plan

Inception

Elaboration

Construction

Transition

Product-ion

consumabilitytasks

globalization and translation focus

  • Architectural “Spikes”
  • Prototyping

integration with other components / products

framework overlapping releases
Framework – Overlapping Releases

Inception

Elaboration

Construction

Transition

Product-ion

Inception

Elaboration

Construction

framework overlapping releases1
Framework - Overlapping Releases

Inception

Elaboration

Construction

Transition

Product-ion

Inception

Elaboration

Warning: Beware of PowerPoint Architects