PM-China 首届产品经理高峰论坛 2011年11月 上海 | 北京
Agile Product Management using Scrum Fujen Chuang 庄富任
Outline •Agile •Scrum Product Management •User Stories and Acceptance Criteria •Estimation and Prioritization •Scrum Process •Q&A
Agile
Why “Agile”? •“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.” - Charles Darwin, The Origin of Species 4
What’s the Pains? •Over Planning
What’s the Pains? •Not What I Want
What’s the Pains? •Locked in
Traditional Waterfall vs. Agile •Waterfall is plan driven while Agile is value driven. •Agile works best with a fixed team taking uncertainty as an acceptable model and does not try to estimate too far into the future. •Traditional waterfall works best when long terms risks need to be understood upfront.
Scrum
Scrum •Scrum is an agile product management framework focus on –Highest priority business value –Iterative & incremental –Regular deliverables and reflection –Collaboration and just-in-time definition –Self organizing
The Scrum Pigpen •Chickens –Management, Stakeholders •Pigs –The Product Owner –The Team –The Scrum Master
Scrum Roles - Product Owner •Owns the vision •Owns the user stories •Owns the priorities
Scrum Roles - Scrum Master •Protects the team from interference •Serves the team to remove blockers •Ensures daily team communication •Supports practice of Scrum
Scrum Roles - Team •Small –7(+/-2) people •Cross-functional •Self-organizing
Scrum Workflow and Artifacts
Product Backlog •Prioritization •Never Complete •Evolve Constantly •Change Dynamically
User Stories
User Stories •Backlog items can be written as “User Stories” •Express user needs in terms of what the user wants to achieve •Example template: –As a <role>, I am able to do <feature> so that [goal] •Includes acceptance criteria
Purpose of User Stories •User stories focus on customer value. •Foster a higher level of collaboration between the chickens and pigs. •A user story is a metaphor for the work being done, not a full description of the work. •The actual work being done is fleshed out via collaboration revolving around the user story.
Requirements, Use Cases, User Stories •Traditional Requirements –Focus on what the system should do, not on the user or business workflow. •Use Cases –A use case is a series of interactions by the user (Actor) with the system and the response of the system. •use case diagrams (workflows, business flows) •use case text –system and user interaction in a call-and-response format. •User Stories –Narrative texts focusing on the value a user gains from the system. –collaboration and just-in-time definition—make user stories a good agile tool.
Model •I: Independent –Reduced dependencies •N: Negotiable –Details added via collaboration •V: Valuable –Provides value to the customer •E: Estimable –Too big or too vague = not estimable •S: Small –comfortably achieve in the duration of a single iteration •T: Testable –Good acceptance criteria
Suggestions for User Stories •State an intent not a solution – . “The user can choose an account” rather than “The user can select the account from a drop-down” •Are independent of implementation –ideally the phrasing would be the same regardless whether this feature/story would be implemented on . web, mobile or a voice activated system •Not every detail needs to be in writing
The Purpose of Acceptance Criteria •What Should be Done –Knowing what needs to be done in order to satisfy the user story. •Relatively high level –Detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration. •Enrich the understanding of the story •Derive test cases
Acceptance Criteria . Test Cases •Acceptance criteria answer the question –“How will I know when I’m done with the story?” •Test cases answer the question –“How do I test and what are the test steps?” •In order to limit scope, user stories have collaboratively developed acceptance criteria which define when the user story meets the stakeholder’s expectations. •Test cases are often developed as code (with test driven development) or documented as the code is developed.
Estimation and Prioritization
Estimate These # Animal Estimate Pig Rabbit Lion Monkey Elephant Tiger Donkey Cat
Story Sizing •Story Points Backlog item Estimate –Agreed-upon unit As a guest, I can add one photo –A measure of the relative to my profile page size of a feature As a premium member I can add up to ten photos to my profile •Fibonacci (1,2,3,5,8...), page Powers-of-2 (0,1,2,4,8...), and As a premium member, I can add Clothes size (XS, S, M, L, XL) video to my profile page –Based on how much and As a guest, I can add photos to my profile pagehow hard to do As a user I can create a profile to –Helps compare costs display information about myself As•Ways of Estimating a user I can add people I like to a “hot list” –Planning Poker
How Small Should a User Story be •Ideally, in 1 to 2 working days for one developer
Prioritization - Kano Analysis •Must have –Functional barriers to entry—without these capabilities, customers will not use the product •Surprise and delight –Capabilities that differentiate a product from its competition •Nice to have –Dimensions along a continuum with a clear direction of increasing utility
Scrum Process Using a 3-weeks iteration as an example
ScScrumu Mmeetin gPs inr a o3-Wdeeuks ct ManagementOwnerTue (1)Wed (2)Thu (3)Fri (4)Mon (7)Tue (8)Wed (9)Thu (10)Fri (11)Mon (14)Tue (15)Wed (16)Thu (17)Fri (18)Mon (21)TuePMSprintIteration Scoping (T + 1)Stories Development (T +1)Stories Refinement (T+1) Product MStories Validation (T)Sprint eetingSprint Review & Planning Product Planning DevRetrospect Meeting Implementation (T)Implementation & Code Complete (T)MeeDebug (T)tingMeeting S(for T)tories Review and Estimation (T+1)(for T)(for T+1)QATest Plan Development (T)Testing (T)Testing (T)RPSpreorvidineutw cPt al Pannladnn Rineignt rMgo sMepeetecintigvn eg Meeting - RAedvjuieswt f ethaetu wreosr ka nthda pt rwioarsit yco emveprlye tietd and not completed Input:ertion (sprint), according to -b uThsien etessa mva dlueem o complete works -Product Owner proposes which user stories in product backlog go - Accept or reject work Results into the sprint -The team provides an estimate of each story Output: - The team commits stories to be completed
ScPrroudumct Pla nPningroduct Management Process OwnerTue (1)Wed (2)Thu (3)Fri (4)Mon (7)Tue (8)Wed (9)Thu (10)Fri (11)Mon (14)Tue (15)Wed (16)Thu (17)Fri (18)Mon (21)TuePMIteration Scoping (T + 1)Stories Development (T +1)Stories Refinement (T+1)Product Stories Validation (T)Sprint MeetingSprint Review & Planning Product Planning DevMeetImplementation (T)Implementation & Code Complete (T)MeetingDebugRetrospect (T)ing Meeting S(for T)tories Review and (for T)Estimation (T+1)(for T+1)QATest Plan Development (T)Testing (T)Testing (T)Owner/Participants Owner/Participants Owner/Participants Chickens and Product Owner Chickens, Product Owner Product Owner and Team 1st Week Product Planning and Team 3rd Week Before Sprint Meeting 2nd Week Product Planning Meeting Input: A high-level prioritized Planning Meeting Review and refine stories product backlog Input: Proposed stories for Output: Proposed stories for the the next sprint next sprint (T+1) Output: Stories for the next sprint (T+1) in details
Scru Product ManagementOwDevenlopemernt anTd uQAe Pr oc(e1ss )Wed (2)Thu (3)Fri (4)Mon (7)Tue (8)Wed (9)Thu (10)Fri (11)Mon (14)Tue (15)Wed (16)Thu (17)Fri (18)Mon (21)TuePMIteration Scoping (T + 1)Stories Development (T +1)Stories Refinement (T+1)Product MStories Validation (T)Sprint eetingSprint Review & Planning Product Planning DevMeeting Implementation (T)Implementation & Code Complete (T)MeetingDebugRetrospect (T)Meeting S(for T)(for T)tories Review and Estimation (T+1)(for T+1)QATest Plan Development (T)Testing (T)Testing (T)Owner/Participants Owner/Participants Owner/Participants Developers Developers Developers 1st Week of Sprint T 2nd Week of Sprint T 3rd Week of Sprint T Implementation and complete Implementation and Debug complete stories codes (T) complete codes (T) Sprint (T+1) stories review Sprint (T+1) stories estimation Owner/Participants Owner/Participants Owner/Participants QA QA QA 1st Week of Sprint T 2nd Week of Sprint T 3rd Week of Sprint T Test cases implementation (T) Testing (T) Testing and verifying all completed stories Sprint (T+1) stories review Sprint (T+1) stories estimation
Are We Doing Scrum ? •Iterations are longer than 2-4 weeks •Team tries to complete specification before programming •An iteration does not include testing •Iteration does not produce workable code •Detailed plan and accurate estimates are expected at the beginning of a sprint •The sprint plan doesn’t reflect what the team is doing •There is little co-operation within the team
Thank You! Q&A
