Download - Agile Project Management

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 PixtonFounder, Accelinnova

President, Evolutionary SystemsDirector Institute of Collaborative Leadership

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

Agenda

What is Agile Agile Methods Scrum Deep Dive Estimating and

Planning Getting Started Leading Agile

What is agile?

“Find your joy in something finished, and not a thousand things begun.”

- Douglas Mallock

Project Methods

Waterfall: Function Definition, Design, Build, Check

FunctionsDesign

Build

Check Done New Methods:

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

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

8

As Knowledge increases Leaders use

iterations to guide project towards enhanced goal

Agile Encourages Mid Course Corrections

Planned Path

Actual Path

Actual Completion

Start

Zone of successPlanned

Completion

Incr

easi

ng K

now

ledg

e

Business Driven – Faster & More Rewarding

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.

Time

Cos

t

Profit

InvestmentB

reak

even

Single Release

Sel

f-Fun

ding

Bre

akev

enSoftware by Numbers by Mark Denne and Jane Cleland-Huang

StagedReleases

Agile Defined…

uses continuous stakeholder feedback

principles

end users partnersinsiders

uses continuous stakeholder feedback

…to deliver high quality,

consumable working

code/features

… through user stories

…and a series of short, stable, time-boxed iterations.

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 Agile?

A development process that conforms to the values and principles of the Agile Alliance(agilealliance.org)

Originally for software development

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: Iterative and Incremental to deliver working

software Light-Weight Meets Changing Needs of Stakeholders Highly Collaborative: Involves Customers Minimizes Documentation Test First

Example: Legacy Highway

Agile Principles

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

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

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

• Short, Stable, Time-Boxed Iterations• Stakeholder Feedback• Self-Directed Teams• Sustainable Pace

The Process Pendulum

Code and Fix WaterfallAgile

No Process PrescriptiveEmpirical

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 Methods

Done?

Planning

Project Definition and Iterations

Completed Deliverables

Review and AdjustImplement

Envision Iterate:

Plan Implement Done? Adapt

CompleteYES

NO

Agile Cycles

Vision

Planning

Develop

Iteration PlanReview / Adapt

Iteration PlanningIterations Plan

High Level Planning Detailed Planning

How Does Agile Work?

“Requirements” called features, defined using user stories:

As a <user/role> … I want to <goal> …

so that <value>.

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 ‘Process’

Test cases are written first, before anything is developed

Go/no-go decisions reached early and often

Agile MUST be DisciplinedAgile development necessitates greater discipline

than traditional methods.

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

“It is a bad plan that admits to no modifications.”

-- Publius Syrus (ca. 42 BCE)

Project Management

What is agile

Summary

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

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

Your Questions?

Project Management

Remove Obstacles

Agile Methodologies

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 Overview

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

XP Thought Leader

eXtreme Programming

XP Values and Principles

Communication Simplicity Feedback Courage Quality Work

XP Practices

The Planning Game Small Releases Metaphor Simple Design Refactoring Test-First Development

XP Practices

Pair Programming Collective Ownership Continuous Integration Sustainable Pace On Site Customer Coding Standards

XP Roles

The CustomerSets project goals and makes business decisions

The DeveloperTurn customer stories into working code

The TrackerKeeps track of any metrics used by team

The CoachGuides and mentors team

Scrum Roles

Scrum Team Scrum Master

Carries water and moves boulders Product Owner

Responsible for maintaining product backlog

Scrum Control Points

Meetings: Sprint

Planning Daily

Scrum Sprint Review

(retrospectives and demo)

Feature Driven Development (FDD)

Deploy

BuildFeature

ListPlan By Feature

Design byFeature

Build ByFeature

DevelopModel

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

- Jeff deLuca, 1997

FDD Focus

(Object) Modeling centric Client centric Architecture centric Pragmatic Functional decomposition

Subject Area Business Activity Business Activity Step

FDD Roles

Chief ProgrammersTeam lead, mentor, developer

Class ownerDeveloper with responsibility for a class

Feature teamsTemporary groups of developers formed around classes

Crystal Clear

Frequent Delivery Reflective Improvement Osmotic Communication Personal Safety Focus Easy Access to Expert

Users Automated Tests Configuration

Management Frequent Integration

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

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

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

Scrum FDD XPCrystalProject Management Engineering

Scrum FDDXPCrystal

StructuredUnstructured

Structure

MethodologyDSDM

DSDM

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

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

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

Why Use Agile …

Project Challenges

Project Statistics

0 10 20 30 40 50 60

Failed

Challenged

Succesful

20061996

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

Project Statistics

Improvements Due To Better: Tools Project Managers Adaptive Methods

Breaking projects into small chunks

Delivering pieces faster for user feedback

Always or Often Used:

20%

Never or Rarely Used:

64%

Standish Group Study, reported by CEO Jim Johnson, XP2002

Sometimes16%

Rarely19%

Never45%

Often13%

Always7%

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

User involvement Management support Clear vision & objectives Proper planning Realistic expectations Smaller milestones Competent staff Ownership

Challenges

Deliver the right product 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

Deliver Business Value

Increase Productivity Lead Change Find Solutions Innovate

Companies Must…

Project Management

Remove Obstacles

Agile Methodologies

Summary

Agile Methods Summary

eXtreme Programming, XP Scrum Feature Driven Development, FDD Crystal Methods Dynamic Systems Development

Method, DSDM Lean Development

User Stories

Your Questions?

Scrum Deep Dive

Scrum on a Page

RolesProduct Owner

ScrumMaster

TeamStakeholders

Artifacts

Meetings

ProductBacklog

ReleaseBacklog

SprintBacklog

BlocksList

Information Radiator

Sprint PlanMeeting

DailyScrum

Sprint ReviewMeeting

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

Release PlanMeeting

Definitions

Roles

Stakeholders

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

Types of Stakeholders

Principals Stakeholders who champion the need for your software and have the authority to acquire and deploy it.

End Users Stakeholders who personally interact with your software.

Partners Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators.

Insiders Stakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.

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

“ “

Understanding Your

Stakeholders

Understanding Organizational

Context

Making Products

Consumable

Aligning with stakeholder

goals

Defining Success in

Your Stakeholders’

Term

Outside-In Software Development

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.

I can’t imagine a world without

Your product

Not only could Iimagine a worldwithout it, I longFor it

Without it, ourbusiness wouldsuffer, and Iwould feel asense of personal loss

It usually doeswhat we want,if painfully attimes

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

from you effortlessly.“

“

Product Owner Prioritizes backlog in collaboration with …

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 Master Is not the project managerTeam manages itself

Doesn’t have authority over the teamTeam 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

Team Add self organizing and ownership bits here.Teams

Unleashing Innovation

Collaboration Process

Exercise

Quick Exercise (A)

1. Form pairs2. Assign one as boss, the other as worker3. The boss can give the following commands:

Go, Stop, Right, Left, Faster, Slower4. The worker must follow the boss’s

commands5. Goal: 60 steps in two minutes6. The boss can command the worker but not

touch the worker

Quick Exercise (B)

1. Everyone is a worker and responsible for figuring out how to proceed during the exercise

2. Goal: 60 steps in two minutes

“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

example:

self-organizing teams:

3M

Coders/programmers

Project Managers

ID/Writers

Testers Other Roles

Prod

uct C

ham

pion

Prod

uct O

wne

rA

rchitectD

esigner

The “Whole Team” Concept

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 McKinneyVP MSM DevelopmentPitney Bowes

Trust/Ownership Model

Command & Control

Team Does as InstructedNo Ownership

Leader / Processis Bottleneck

Conflict

Team DemotivatedMired in Bureaucracy

& Wasted Effort

Energy & Innovation

Team TrustedTeam Accountable

Leader Freed

Failure

No One Cares

High

How do we

get here?

Team/Individual OwnershipControl

Trust

Low

Lead

ersh

ip&

Bus

ines

s Pr

oces

s

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 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?

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.

Two principles supporting the Agile Manifesto:

DefinitionsRolesSummary

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

Artifacts

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

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

Each Sprint has a goal Team agrees on goal and commits to it User Stories for the Sprint

Blocks List

Internal – Actions within the team External – Actions beyond the team Updated by the Scrum Master Scrum Master resolves them with team


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

Part of the Information Radiator

Example

ArtifactsSummary

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

Leadership InfluenceMeetings

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 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 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 ScrumRecords Sprint Backlog up to date Scrum Master updates the blocks list

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

Only DONE working user stories. Ask for attendance from the following for the

first 4 iterations as numbered:1. Executive2. Internal users3. Stakeholders4. Customers

How do you know when you’re “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 “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

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

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

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

Keep Drop Add

Keep? Drop? Add? What surprised you?

Leadership Influence

MeetingsSummary

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.



Scrum Exercise

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 2 minute Daily Scrum Meeting 8 minute day

Demo & Reflection

1009080706050403020100

080706050403020100

020100 080706050403020100

020100 080706050403020100

Scrum Deep Dive

Summary

Scrum on a Page

RolesProduct Owner

ScrumMaster

TeamStakeholders

Artifacts

Meetings

ProductBacklog

ReleaseBacklog

SprintBacklog

BlocksList


Sprint PlanMeeting

DailyScrum

Sprint ReviewMeeting

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

Release PlanMeeting

Scrum Best Practices

Test Driven Development Pair testers and developers Continuous Integration

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

References

Agile Project Management with Scrum, Ken Schwaber

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle

Scrum Deep Dive - QuestionsScrum Deep Dive Questions?

Leading Agile

Collaboration Model Collaboration Process

User Stories

User Stories Overview

BasicsCreatingRefineFlow

Leading Agile


User Story Basics

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 RolesAs 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 GoalsAs 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 ValueAs 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

Example

As an < astronaut > I can < write easily while in Zero gravity >

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

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

At your table, build three 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 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

Value to Stakeholders Stories target functionality valuable to

stakeholders Story demos each iteration engage

stakeholders


Simplified Features Stories enable light-weight

requirements gathering, progressive discovery

Stories focus on feature essentials


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 Agile


Creating User Stories

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

Principals Stakeholders who champion the need for your software and have the authority to acquire and deploy it.

End Users Stakeholders who personally interact with your software.

Partners Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators.

Insiders Stakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.

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

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.


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?


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



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




Exercise

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

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 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 Team

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

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 Agile


Refining User Stories

Project Management

How Do We Deliver?

Breaking stories into smaller stories

Using User Stories

Break Epic User Stories into smaller User Stories

Break Epics for the next one (or two) releases User Stories by definition fit 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 StoriesSuccessful 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?

Cross-disciplined scrum team that will deliver the story

Stories are sized in "story points" – relative to one another

Based on the team’s skillsBased 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 Stories?

What if you cannot size a story? May need more domain knowledge, have

more conversations If technology is unknown, use architectural

spikesShort (time-bounded) iteration to learn “just

enough” to proceed

Break Stories into Smaller Stories

As a BuildForge Admin I want to install & run BuildForge server

components on the AIX platform to manage it within my

defined IT standards and the skill sets of my system

administrators

Wizard-like installation process using default

parameters

Silent installation using default parameters

Installs all pre-requisite components

...

User Stories

Recommendation:Do not maintain a hierarchy of stories under an epic

Easier to manage a flat list of user storiesHierarchical stories overcomplicate the backlog

Hard to remove smaller stories

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

Complex DataDisplay Grid

Data-base

QueryBuilder

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

CREATE

READ

UPDATE

DELETE

Remove Cross-Cutting ConcernsConsider 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

Attribute Explanation

Independent Does not depend on other stories

Negotiable Not all details necessary

Valuable Has tangible value to stakeholders of the software

Estimate-able You can estimate stories via story points

Small Fits in an iteration by definition

Testable Required to demonstrate that story is “done”

INVEST ( From Mike Cohn)

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 Agile


User Stories Flow

Flow: The Big Picture

SelectHigh-priorityStories

Create/sizeUser

Stories

Trawl forRequirements

Time Boxed Iteration

Demo Working Code to

Stakeholders

Reflect& Take Action

Epics

Stories

Iteration Backlog

Get Feedback

ReleasePlanning

StakeholderGoals

Refine Stories,Plan Work

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

Epics

Stories

ReleaseBacklog

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

Map content released functionality iteratively

1: Input an address and see the location on a street map2: Input two addresses and get directions between them3: 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 workedGet “enough” functionality out sooner Discover what feature to add next based on feedbackJun/10 181

User Stories Summary

User Stories Overview

Basics Creating Refine Flow

Terms

Epic User Story User Stories Release Themes Champions Architecture Spikes

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 Stories

Your Questions?

Reflection

Key Characteristics of Successful Agile Projects

• Short, Stable, Time-Boxed Iterations• Stakeholder Feedback• Self-Directed Teams• Sustainable Pace

Project Framework

Project Framework - Iteration Plan

Inception Elaboration Construction Transition Product-ion

consumability tasks

integration with other components / products

globalization and translation focus

• Architectural “Spikes”

• Prototyping

Framework – Overlapping Releases


Inception Elaboration Construction

Framework - Overlapping Releases

Warning: Beware of PowerPoint

Architects


Inception Elaboration