Upload
eric-krock
View
1.960
Download
1
Embed Size (px)
DESCRIPTION
Brief introduction to Agile Project Management and Scrum covering user stories, story points, use of Fibonacci sequence values for story points, release planning, sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts. Explains the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic. Summarizes the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work). Discusses values and best practices in Agile/Extreme Programming ("XP") values. Explains daily standup meeting in which people share what they did yesterday, what they’re doing today, and any blocking issues they’re encountering. Summarizes common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch. Summaries problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers.
Citation preview
Eric Krock Co-‐Founder, Voximate
http://twitter.com/#!/voximate http://www.voximate.com/blog/
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
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
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
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
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”
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
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
Development Concepts Test driven design* Depth-‐first development
* Source: Kent Beck, XP Explained
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
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
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
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
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
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
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 event 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
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
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
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 & Cynthia Andres
Introduction to XP
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/