Eric

Krock Principal Consultant and Trainer, 280 Group

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Why Waterfall Usually Sucks

Problem Serialized process: MRD PRD Design Document Dev - QA Planning far in advance Lack of visibility into rate of progress Consequences Longer time to market; developers isolated from customer needs Plans no longer match reality by the time theyre implemented Teams dont realize theyre behind schedule until too late Features slashed very late to compensate, wasting eort and leading to Swiss-cheese products (e.g. MS Kin) Customers get access to new features infrequently and after long delay Customers can only provide feedback too late Process doesnt allow for rapid incremental learning

Long time to project completion

Projects fall behind Projects miss market window or are killed before schedule launch 2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Why PRDs Usually Suck

Long Monolithic Unreadable and unread Often disconnected from actual customer needs Lack of clarity about what features are for which

customers

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

User Stories
Express a customer need as a story about a real or

composite user in the language of the customer As a [USER ROLE], I [must / want / wish to] [need] so that [user goal] Short: can t on an index card Example: As a project manager, I must track each tasks delivery deadline so that I can make sure tasks are completed on team. Small amount of work: can t within a day or a sprint Should include notes for needed acceptance test
Source: Mike Cohn, User Stories Applied
2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Es7mate Eort for Story in Points

Story point = abstract, RELATIVE estimate of

amount of work to complete a story Optional: Using Fibbonacci sequence forces clear distinctions in diculty: 1, 2, 3, 5, 8, 13, 21 Teams must agree on estimate for each story Tracking velocity (points completed per sprint) will measure teams true capacity Issues: measure with points, or not?

Source: Mike Cohn, Agile Estimating and Planning

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Release Plan
Combines multiple sprints to achieve larger goal Capacity = number of sprints * expected velocity Choose list of stories with total story points no greater

than capacity

Source: Mike Cohn, Agile Estimating and Planning, Chapter 13, Release Planning
2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Divide Workload Into Short Sprints

Sprint = short, xed-length interval for development Usually 1-2 weeks Key: Must return product to potentially shippable

state at end of sprint!

Reduces accumulation of technical debt Keeps assessment of project progress realistic

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Key Concepts in Scrum

Product Owner: voice of the customer, facilitates

writing of user stories ScrumMaster: manages the sprints Team: do the work! Collective ownership Daily standup: did yesterday, doing today, stuck on

Source: Mike Cohn, User Stories Applied, Chapter 15

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Development Concepts
Test driven design* Depth-rst development

* Source: Kent Beck, XP Explained

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Sprint Commit Mee7ng

At start of each sprint, team meets and commits

which stories they will do for the sprint. Make decision based on tasks for each story and estimated hours for all tasks, not based on points. Key: After sprint commit meeting, no new stories can be added to that sprint.
For true emergencies, must remove equal amount of

work if add something in after sprint commit.

Source: Mike Cohn, User Stories Applied

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

User Stories Conversa7ons

User story is basis for a conversation with developer Conversation (not the user story) is basis for actual

development Goals:
Get engineering talking to product owner, customers,

etc. Get deeper mutual understanding of the story by talking about it Increase odds that features developed will actually satisfy customers needs
Source: Mike Cohn, User Stories Applied
2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Sprint Burndown Chart

Sprint Hours of Work Remaining
70 60 50 40 30 20 10 0 3/27/11 3/28/11 3/29/11 3/30/11 3/31/11 4/1/11

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Sprint Review Mee7ng

At end of sprint, review what work actually got done. Velocity = total points for all user stories completed

during sprint. No partial credit for partially-complete stories! Estimated time to project completion = total story points for all stories in project / moving average of velocity Moving average = average velocity of last three sprints Teams accuracy estimating doable work per sprint should improve over time
Source: Mike Cohn, Agile Estimating and Planning
2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Project Burndown Chart

400 350 300 250 200 150 100 50 0
1/7/11 1/14/11 1/21/11 1/28/11 2/4/11 2/11/11 2/18/11 2/25/11 3/4/11

Points Closed Points Added Points Remaining

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Backlog: Per-Project, or Per-Release?

Backlog is list of all stories not yet assigned to a sprint Simple project, single release: single backlog Benet: simplicity Long-lived project with multiple releases: may have

one backlog per release

Benet: do initial division of work by release, then

divide each releases work into sprints during development; product owner neednt review ALL stories at every sprint

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Agile Best Prac7ces

Best Practice Benet Dont write stories too far in advance of Avoid wasted eort on stories that are development.* not implemented. Use best, most-current information when writing story. Dont even tentatively schedule stories more than 2-3 sprints in advance. Have customers write and prioritize user stories.* Avoid wasted eort of moving stories when priorities change. Let customers express their needs. Avoid telephone game problem. Force customers to make tradeos.

* Source: Mike Cohn, User Stories Applied

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Key Agile Values

Communication Transparency Honesty Incremental eort Incremental learning feedback

For fuller list of Agile / XP values, see Kent Beck, XP Explained, Chapters 3-5
2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Agile Versus Tradi7onal Waterfall

Metric Planning scale Distance between customer and developer Time between specication and implementation Time to discover problems Project schedule risk Ability to respond quickly to change Waterfall Long-term Long Long Agile Short-term Short Short

Long High Low

Short Low High

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Addi7onal Reading
Book User Stories Applied Agile Estimating and Planning Succeeding with Agile Author Mike Cohn Mike Cohn Mike Cohn Notes Intro to Agile and use of user stories for expressing requirements. Deep dive on Agile metrics, estimating, and project planning. Tips on rolling out Agile in a larger organization. Introduction to XP

Extreme Programming Kent Beck Explained

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Addi7onal Resources
http://www.mountaingoatsoftware.com/

Mike Cohns site with blog, presentations, more http://agilemanifesto.org/ http://www.agilealliance.org/ http://www.scrumalliance.org/

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.

Stay in Touch!
http://www.linkedin.com/in/krock http://www.slideshare.net/ekrock/ My email list: http://eepurl.com/jon-f ericweb@mail.com

2011-2012 Eric Krock Marketing Services Inc. All rights reserved.