Your SlideShare is downloading. ×
  • Like
Scrum and agile principles
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Scrum and agile principles


Slides used to introduce Scrum at the DevCon, July 13, 2013. At the Orange & Bronze HQ, Makati.

Slides used to introduce Scrum at the DevCon, July 13, 2013. At the Orange & Bronze HQ, Makati.

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Scrum Ruben D. Canlas Jr. • From The Scrum Primer by Pete Deemer, et al. (Available on the web) • The Elements of Scrum by Chris Sims and Louise Johnson • Scrum Reference Card by CollabNet.
  • 2. • Plans are nothing; planning is everything. • – Dwight D. Eisenhower.
  • 3. Project Management
  • 4. Outline •  What is scrum? •  Agile principles and values •  How to increase the success of shifting to scrum 4
  • 5. Activity: Amazing Race • How would planning be different if you were in The Amazing Race versus a Europe group tour?
  • 6. Group Tour versus Amazing Race Amazing Race Europe Group Tour Goal Vague idea of finish line. Some details available but most are unclear. Details known before hand. Itinerary likely to be followed. Strategy Make some plan but be ready to abandon/adjust per leg of the race. Stick to the itinerary. Learning/ coping method Teams discover new details per leg of the race. Regular pit stops allow teams to assess and course-correct. Rely on tour leader. Decision making Empowered, self organizing teams. Decisions mostly made by tour leader.
  • 7. Amazing Race and Scrum Amazing Race Scrum Goal Big goal (global race) with no idea of finish line Big goal contained in Product Vision. Product Backlog contains coarse-grained feature list. How to reach goal Big goal broken down into legs per country. Teams finish each leg of the race and proceed to next. Product Backlog broken down into manageable chunks (sprints) with shippable products per sprint. Learning method Teams discover new clues per leg of the race. Regular pit stops allow teams to assess and course-correct. Team discovers and refines features per sprint. Reflection/ inspection after every sprint help teams to improve. Adapting to Surprises Each team makes own decisions to adjust quickly to new challenges. Dev Team and PO make decisions to adapt to surprises. (SM facilitates)
  • 8. Self Organizing Teams (aka High Performance Teams or HPTs) •  Tightly knit •  Empowered to make decisions •  Working to deliver a common goal •  Can surmount any obstacle, solve any problems, no matter what
  • 9. Scrum is appropriate in high uncertainty (eg software or product development) -- Based on CollabNet Traditional Project Management Learning or Adaptive Teams
  • 10. The Agile Manifesto •  We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan •  That is, while there is value in the items on the right, we value the items on the left more.
  • 11. Make everything visible or known to stakeholders: plans, schedules, issues, etc Stop and review the product & the process Self-correction based on results of inspection The 3 Scrum Principles The Scrum Master must ensure that the team members adhere to these 3 principles, always.
  • 12. Scrum/Agile is Visual: Scrum Team after Daily Standup, reviews and updates tasks
  • 13. SCRUM •  Agile method for developing software •  Capitalizes on self organizing teams (aka High Performance Teams) •  Based on Lean Principles
  • 14. Rituals, Practices & Artifacts Scrum in a Nutshell
  • 15. s
  • 16. Roles: the primary stakeholders of Scrum
  • 17. Rituals & practices: regular activities that the Scrum must perform in order to work well
  • 18. Artifacts: important documents and related habits
  • 19. Important •  Sprint Review: to inspect and improve (adapt) the product •  Sprint Retrospective: to inspect and improve the team’s process
  • 20. Product Backlog sample (owned by PO) Size estimates: 1, 2, 3, 5, 8, 13, 21, 34, 55, BIG
  • 21. Sprint Backlog sample (owned by DEV)
  • 22. Sprint Planning Zoom in on a critical Scrum ritual
  • 23. Sprint Planning, Part 1 •  Goal: Find out what the PO wants and define shared goals for this sprint PO and Team review high priority User Stories Discuss this sprint s goals and context behind the product User Stories = Product Backlog Items Team tries to gain insight into the PO s thinking (what PO wants) Notes: • SM facilitates the process/discussion • Assumes Product Backlog has been created and refined with Team s participation • Use the Socratic method (Q & A) to discover/uncover more context and insight Review Acceptance Criteria that all User Stories must meet Eg: Done means coded to standards, reviewed, implemented using TDD, tested by users, integrated, and documented
  • 24. Sprint Planning, Part 2 (Overview) •  Goal: Task planning: how to implement the User Stories (Product Backlog Items) Notes: • PO optional in Part 2, but must be within reach (eg by phone) to answer questions • The Team chooses the tasks; PO or SM does not assign them. • This increases Team buy-in and confidence in self-organizing. Optional: Estimate available time for this sprint (hrs/day) Discuss the design of the solution Decompose User Stories into tasks (Sprint Backlog) Start from first User Stories (highest priority) Sprint capacity estimation per member Tip: Use whiteboard for more visual discussion Members take on sprint tasks based on capacity Until all sprint capacity is used up
  • 25. Day to Day for Scrum (2-week sprint) •  Monday: Sprint Planning: (9-12:00) •  Tue: daily scrum •  Wed: daily scrum •  Thu: daily scrum •  Fri: daily scrum •  Monday: Tue: daily scrum •  Wed: daily scrum •  Thu: daily scrum: Prod backlog grooming (virtual): PO only •  Fri: Sprint Review; Sprint Retro Recommended level of effort: Dev Team must be full time PO must be be accessible to the Dev Team SM must be full time
  • 26. Notes on doing the rituals/meetings •  Prefer face to face meetings always •  If not possible, use voice calls or voice internet chat •  Last resort: text-based communication, eg SMS, email, Basecamp •  Reason: face-to-face is faster and more efficient over other methods •  Daily scrums are important because we could instantly find out any delays and help capture problems and facilitate resolution on a daily basis •  During a Scrum Retro: •  Pick only 2-3 problems to solve in the next sprint (instead of a long list of resolutions) •  Reason: 2-3 problems are more solveable than a long list of resolutions; solve the other problems in the succeeding sprints
  • 27. Best practice meeting durations •  Sprint Planning: 2 hrs for a 2 week sprint •  1 hr per 1 week sprint •  Sprint Demo: 1-2 hrs for a 2 week sprint •  30-60 min per 1 week sprint •  Sprint Retro: 2-4 hrs for a 2 week sprint •  1-2 hrs per 1 week sprint •  Story Time (aka Product Backlog Grooming): 60-120 min for a 2 week sprint •  30-60 min per 1 week sprint
  • 28. Sprint Retro •  What do we need to stop doing? •  What do we need to start doing? •  What do we continue?
  • 29. Sprint Backlog sample
  • 30. The Scrum Team is composed of Roles: •  Product Owner (PO) •  Scrum Master (SM) •  Development Team (DT or The Team) The Scrum Team is a self-managing team that focuses on team learning.
  • 31. Product Owner (PO) •  Responsibility: maximize business value (aka return on investment, ROI). •  Defines and owns the Product Vision •  Represents the business and customers •  Owns the Product Backlog •  Identifies and prioritizes product features/stories •  Creates acceptance criteria for stories •  Always available to answer team questions •  Aka chicken There should be only one PO per project.
  • 32. Product Owner •  Final arbiter of requirements questions •  Accepts or rejects each product increment •  Decides whether to ship •  Decides whether to continue development •  Considers stakeholder interests •  May contribute as a team member •  Has a leadership role
  • 33. Development Team (DT or Dev) •  Goal: delivers the user stories (aka, the product features) •  Builds the product (software, website, new gadget). •  Self-organizes to deliver user stories •  Owns the estimation process •  PO and SM must be able to trust the DT in making estimates •  DT must get better and better at making estimates •  Owns the how to do the work decisions •  Avoids not my job syndrome: must use self-organization to learn how to overcome obstacles Ideal Dev Team number: 5 to 9 developers including programmers, analysts & designers, GUI designers/ programmers, documentors, etc
  • 34. Development Team (DT or Dev) •  Cross-functional: includes all expertise needed to deliver potentially shippable product after each sprint. •  May include people with skills in analysis, development, testing, interface design, database design, architecture, documentation, and so on. •  Goal is for each member to work out of their comfort zones/expertise and learn something new •  Decides how best to accomplish the user stories. (PO decides what user stories to prioritize in a sprint.)
  • 35. Scrum Master (SM) •  Goal: deliver a self-organizing team •  Self-organizing team: a team that embraces the principles of agility: transparency, inspect, and adapt •  A team that makes problems visible and can self-adjust to solve them •  One way to look at SM role is as facilitator of group learning •  Scrum expert, coach, and advisor •  Must help PO and DT understand and live the Scrum way •  Evangelist: Makes sure everyone (including team and management) buys into Scrum practices and principles •  Impediment bulldozer: helps the team remove obstacles •  Change management: help lead the organization through the often difficult change required to achieve success with agile development. The SM only facilitates. Unlike a Proj Mgr, the SM does not make decisions about products, priorities, and schedules.
  • 36. Artifacts (Details)
  • 37. Product Vision •  Big picture: True North, The Finish Line •  Identifies the users •  Captures the essence of the product; sells the product to stakeholders •  Objectives •  Defines the value of the product to the organization/users
  • 38. Exercise: writing your Product Vision 1. Who is going to buy/use the product? Who is the target customer?  2. What customer needs will the product address?  3. What product attributes are critical to satisfy the needs selected, and therefore for the success of the product?  4. How does the product compare against existing products, both from competitors and the same company? What are the product s unique selling points?  5. What is the target timeframe and budget to develop and launch the product? 6. Who do you need to consult further? 7. What information (documents, flowcharts) do you need? Are they up-to-date? Does everyone agree to them?
  • 39. Product Backlog •  Force-ranked list of desired functionality •  Visible to all stakeholders •  Any stakeholder (including the Team) can add items •  Constantly re-prioritized by the Product Owner •  Items at top are more granular than items at bottom •  Maintained during the Backlog Refinement Meeting
  • 40. User Stories (aka Product Backlog Item or User Stories) •  Specifies the what more than the how of a customer-centric feature •  Often written in User Story form •  Has a product-wide definition of done to prevent technical debt •  May have item-specific acceptance criteria •  Effort is estimated by the team, ideally in relative units (e.g., story points) •  Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams
  • 41. Sprint Backlog •  Contains the User Stories chosen for a particular sprint •  From the User Storiess, we create an itemized list of tasks to deliver the User Stories •  Represents the Dev Team s commitment to deliver for that sprint •  Contains refined size estimates per task •  Visible to the team •  Referenced during the daily scrum
  • 42. Sprint Backlog daily tracking is better if visible
  • 43. References •  From The Scrum Primer by Pete Deemer, et al. (Available on the web) •  The Elements of Scrum by Chris Sims and Louise Johnson •  Scrum Reference Card by CollabNet.