1 / 32

Technical Project Manager Certified Scrum Master Manager of Exsilio’s PMO

Technical Project Manager Certified Scrum Master Manager of Exsilio’s PMO. James Burk, PMP, CSM. Eastside Agile/Scrum Meetup Meeting #1 – 12/6/2017. Agenda. Introductions Presentation on Scrum Methodology Best Practices Discussion Roundtable Discussion:

elina
Télécharger la présentation

Technical Project Manager Certified Scrum Master Manager of Exsilio’s PMO

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Technical Project Manager Certified Scrum Master Manager of Exsilio’s PMO James Burk, PMP, CSM Eastside Agile/Scrum Meetup Meeting #1 – 12/6/2017

  2. Agenda Introductions Presentation on Scrum Methodology Best Practices Discussion Roundtable Discussion: • What do you want out of the Meetup? • What topics should we cover in the future? • Do you know any speakers we could invite?

  3. Delivery Methodologies • Agile/Scrum Methodology Advantages: • Early customer feedback • Shorter development cycles • Flexible to changing requirements • Continuous improvement • Value is achieved faster as product is released more frequently • Follows a continuous improvement cycle, exposing flaws faster and reducing waste • Waterfall Methodology • Requirements are well defined • Predictability in schedule & resources utilized

  4. Cone of Uncertainty At the beginning of any project teams have the most uncertainty with a variance of .25 x to 4x. Teams are asked to provide while in high uncertainty exactly what will be delivered, by when and at what cost.

  5. Why Scrum is Good Ideal for projects where requirements are changing and a regular cadence of releases is expected. Fixed length (1-2 week) Sprints are atomic and you are able to release completed functionality. Team can change what they’re doing sprint-to-sprint. Use of more modern tools like TFS/VSO/Jira to manage Sprints.

  6. Scrum Framework

  7. Product Owner The Product Owner’s primary goal is to ensure the vision that was asked for by the stakeholders/customers is being executed by the team. They work with stakeholders to understand the functionality of the system under development and will write user stories or work jointly with customers to write them. The Product Owner manages and represents the interests of the stakeholders and customers

  8. Scrum Team The team executes the Product Owner’s vision with the help of the ScrumMaster. The team is comprised of the people needed to deliver the work – developers, testers, architects, designers – anyone who is needed. A core team is ideally made up of full-time people dedicated to the project. The team is responsible for managing its work, its commitments and the execution of those commitments.

  9. ScrumMaster A good ScrumMaster: Ability to read Non-Verbal Communication Builds Trust and Earns Respect Comfortable with Conflict Dynamics of the team are understood Effective communicator

  10. Sprint Planning Meeting The product owner presents to the team the high priority (value, risk) stories in the product backlog. Team members ask clarifying questions and acceptance criteria. They break the stories into tasks, build the sprint backlog and commit to the work. Once a sprint is agreed to by the team items should not be added/removed from the sprint Story points are reconfirmed Tasks are added to stories to support the completion of the story and estimated in hours

  11. Daily SCRUM The team meets for 15 minutes every day with the purpose of sharing what team members are working on. This is done by answering 3 questions. Each member reports to the team, not an individual. It is up to the team to hold each other accountable to the sprint completion. What did you work on since the last meeting? What will you work on today? Do you have any blocking issues?

  12. Sprint Review The stakeholders sit with the team, ScrumMaster and product owner to review the functionality delivered in the sprint. Changes may come out of this meeting for the next sprint. Guidelines for sprint reviews: Incomplete work cannot be demonstrated The recommended duration is two hours for a two-week sprint (pro-rata for other sprint durations) Opportunity to gather feedback from stakeholders

  13. Retrospective Reflects on the past sprint Occurs shortly after a sprint review Identifies and agrees on continuous process improvement actions Guidelines for sprint retrospectives: Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? The recommended duration is one-and-a-half hours for a two-week sprint (pro-rata for other sprint durations) This event is facilitated by the ScrumMaster

  14. Sample Sprint Cadence

  15. User Stories Short, simple description of a feature told from the user perspective of the person who desires the new capability, usually a user or customer of the system. Independent Negotiable Valuable Estimable Small Testable Stories typically follow a simple template: As a <user>, I can <action> so that <reason>.

  16. Story Points Relative weighting units that measure the effort required to develop a story. They imply a range, and therefore work based on accuracy not precision. Story points are used by the team to estimate the product backlog at the beginning and in grooming. Typically use Fibonacci (1,2,3,5,8,13,21)

  17. Velocity Velocity is the average number of story points a team completes per sprint, as defined by the team’s done criteria. It is a measure over time and provides an indicator of the average number of story points the team can accomplish.

  18. Velocity

  19. Product Backlog A prioritized, ordered list, sorted by business value and risk. It contains the work needed to accomplish the project. The Product Backlog often contains user stories but may also contain functional requirements, nonfunctional requirements, bugs and various issues. The Product Backlog is estimated in abstract units such as story points, which use a relative weighting model.

  20. Sprint Backlog The output of the sprint planning meeting. It is essentially the list of tasks that the Scrum team needs to complete during the sprint in order to turn a selected set of product backlog items into a deliverable increment of functionality. Unlike the product backlog items, sprint backlog tasks have a time based hourly estimate. Since the core scrum team is doing the work, they are responsible for keeping the sprint backlog up to date.

  21. Burndown The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

  22. Burndown - Examples

  23. Burndown - Examples

  24. Grooming Grooming can also be referred to as Requirements Gathering. The product owner spends 5% - 15% of his time with the team to review the updated product backlog. Team revises and assign story point estimates to user stories in the product backlog. No commitments are made in this meeting Ideally, always happening. Good idea to have regular meetings to focus the team on grooming. Activities: Ensure that all items have descriptions, estimates, and are organized correctly. Break large items into smaller ones. Review the prioritization of backlog items with the stakeholder. Define & agree on technical spikes: research, design, & investigation.

  25. Grooming One purpose of the grooming meeting is to help identify an item that could be broken into smaller backlog items. Once a backlog is sized it helps the Product Owner in project planning

  26. Grooming using “Planning Poker” The Development team can make estimating a game by choosing a card the revealing to everyone else at the same time. Either a T-Shirt or number sequence is used.

  27. Limitations of Scrum Requires close interaction between developers. Developers must be able to cross-train and interchange work. Less suitable for projects with many external dependencies or that need specialized testing.

  28. Resources Scrum Alliance Scrum.org ScrumMethodology.com ScrumGuides.org Local CSM Trainers: Mitch Lacey – www.mitchlacey.com Michael James - seattlescrumtraining.com

  29. Q&A

  30. Scrum Best Practices at your organization • Next Steps • What do you want to get out of the Meetup? • Future Topics? • Future Speakers? Discussion

  31. Appendix

  32. Limitations of Waterfall What they don’t show you: Royce’s next comment – “I believe in this concept but, the implementation described above is risky and invites failure.”

More Related