Agile Project Management using SCRUMPresentation Transcript
Agile Project Managementusing SCRUM – Part 1 Bubu Tripathy, PMP
Product Backlog product backlog is the heart of Scrum prioritized list of requirements, or stories or features described using the customer’s terminology Stories include the following fields: ID Name Importance Initial estimate (in story point = ideal man-days) How to demo Notes
Sprint Planning Sprint Planning Prerequisites The product backlog should exist! There should be one product backlog and one product owner (per product). All important items should have importance ratings assigned to them. it is OK if lower importance items all have the same value Stories for the next sprint should have a unique importance level. The product owner should understand each story. Only product owner can assign an importance level.
Sprint Planning contd. Sprint Planning is a critical meeting. Purpose give the team enough information give the product owner enough confidence Output Sprint goal Team members Sprint backlog Sprint demo date Time and place for daily scrum
Sprint Planning contd. Keep in mind: The product owner has to attend the sprint planning meeting. Each story has: scope, estimate, importance Start with most important stories. Direct collaboration is fundamental to scrum. Time-box the sprint planning meeting Have a sprint planning agenda.
Typical Sprint Planning Schedule Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour) 13:00 – 13:30. Product owner goes through sprint goal and summarizes product backlog. Demo place, date and time is set. 13:30 – 15:00. Team time-estimates, and breaks down items as necessary. Product owner updates importance ratings as necessary. Items are clarified. “How to demo” is filled in for all high-importance items. 15:00 – 16:00. Team selects stories to be included in sprint. Do velocity calculations as a reality check. 16:00 – 17:00. Select time and place for daily scrum (if different from last sprint). Further breakdown of stories into tasks.
Sprint Planning Outputs Sprint demo date Sprint length short sprints are good. long sprints are good, too. product owners like short sprints and developers like long sprints. sprint length is a compromise. 3 week is ideal. experiment with sprint length, initially. Once decided, stick to the sprint length.
Sprint Planning Outputs Define the Sprint Goal It’s hard to come up with one! Why are we doing this sprint? It should be in business terms, not technical terms Each sprint must have a new goal. Publish the sprint goal (s).
Sprint Planning Outputs Create the sprint backlog A sub-set of the product backlog
How can product owner affect whichstories make it to the sprint?
How does the team decide which storiesto include in the sprint? Gut feel Velocity Calculation Decide estimated velocity. Calculate how many stories you can add without exceeding estimated velocity.
How to estimate velocity ? Yesterday’s weather Look at the team’s history. Only feasible for experienced teams Future sprints are similar to past sprints Resource Calculation Calculate the ‘Available Man-Days’ for current sprint. Calculate last sprint’s ‘Focus Factor’ Derive current sprint’s estimated velocity
How to estimate velocity ?
Using Index Cards Index cards are superior to excel-based backlogs People stand-up and walk around. (stay awake!) Everybody feels more involved. Multiple stories can be edited simultaneously. Easy Reprioritizing - just move the index cards around.
Definition of “Done” (DoD) Product owner and team must agree on DoD. Usually ready to deploy to production Many teams have a checklist of DoD criteria. It can be as simple as a story marked as “Validated” by a tester. Each type of story may have different DoD criteria. Use common sense. Extreme scenario – DoD field for each story.
Time Estimation using Planning Poker Estimation is a team activity. Every member is involved in estimating each story. ‘Planning Poker’ is an estimation technique (coined by Mike Cohn) Each team member gets a deck of 13 cards. The number sequence on the card is non-linear. This is to avoid a false sense of accuracy for large time estimates. each team member selects a card that represents his time estimate (in story points). All team members reveal the estimates simultaneously. Each team member is forced to think for himself. The team discusses the discrepancies.
Clarifying Stories Make sure that all the fields are filled in for each story. Clearly Understand the scope of the story. Example – “Add User” story. List down the individual activities for a story. The “How to Demo” field must be filled for each story. The worst thing is when the product owner says ““That’s not what I asked for!” during the sprint demo.
Breaking down stories Strive for stories weighted 2 - 8 man-days. Make sure that the smaller stories still represent deliverables with business value. Stories are deliverables that the product owner cares about. Tasks are work that the scrum team needs to do. Product owner does not care about Tasks. Breaking stories into tasks Reveals additional work. Makes daily standup more efficient.