Eric Krock Principal Consultant and Trainer, 280 Group © 20112012 Eric Krock Marketing Services Inc. All rights reserved.
May 08, 2015
Eric Krock Principal Consultant and Trainer, 280 Group
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Why Waterfall Usually Sucks Problem Consequences
Serialized process: MRD – PRD – Design Document – Dev -‐ QA
Longer time to market; developers isolated from customer needs
Planning far in advance Plans no longer match reality by the time they’re implemented
Lack of visibility into rate of progress
Teams don’t realize they’re behind schedule until too late Features slashed very late to compensate, wasting effort and leading to Swiss-‐cheese products (e.g. MS Kin)
Long time to project completion
Customers get access to new features infrequently and after long delay Customers can only provide feedback “too late” Process doesn’t allow for rapid incremental learning
Projects fall behind schedule
Projects miss market window or are killed before 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 fit on an index card Example: “As a project manager, I must track each task’s delivery deadline so that I can make sure tasks are completed on team.”
Small amount of work: can fit 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 Effort 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 difficulty: 1, 2, 3, 5, 8, 13, 21 …
Teams must agree on estimate for each story Tracking velocity (points completed per sprint) will measure team’s 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, fixed-‐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-‐first 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 customer’s needs
Source: Mike Cohn, User Stories Applied
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Sprint Burndown Chart
0
10
20
30
40
50
60
70
3/27/11 3/28/11 3/29/11 3/30/11 3/31/11 4/1/11
Sprint Hours of Work Remaining
© 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 Team’s 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
0
50
100
150
200
250
300
350
400
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
Benefit: simplicity Long-‐lived project with multiple releases: may have one backlog per release Benefit: do initial division of work by release, then divide each release’s work into sprints during development; product owner needn’t review ALL stories at every sprint
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Agile Best Prac7ces Best Practice Benefit
Don’t write stories too far in advance of development.*
Avoid wasted effort on stories that are not implemented. Use best, most-‐current information when writing story.
Don’t even tentatively schedule stories more than 2-‐3 sprints in advance.
Avoid wasted effort of moving stories when priorities change.
Have customers write and prioritize user stories.*
Let customers express their needs. Avoid “telephone game” problem. Force customers to make tradeoffs.
* Source: Mike Cohn, User Stories Applied
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Key Agile Values Communication Transparency Honesty Incremental effort 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 Waterfall Agile
Planning scale Long-‐term Short-‐term
Distance between customer and developer
Long Short
Time between specification and implementation
Long Short
Time to discover problems
Long Short
Project schedule risk High Low
Ability to respond quickly to change
Low High
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Addi7onal Reading Book Author Notes
User Stories Applied Mike Cohn Intro to Agile and use of user stories for expressing requirements.
Agile Estimating and Planning
Mike Cohn Deep dive on Agile metrics, estimating, and project planning.
Succeeding with Agile Mike Cohn Tips on rolling out Agile in a larger organization.
Extreme Programming Explained
Kent Beck Introduction to XP
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.
Addi7onal Resources http://www.mountaingoatsoftware.com/ Mike Cohn’s 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 [email protected]
© 2011-‐2012 Eric Krock Marketing Services Inc. All rights reserved.