What You Will Learn
Students self-organize in Scrum Teams at the beginning of the course and are presented with a real-life software-based case study. During the course, they practice the Scrum Framework in multiple realistic Sprints, during which they are gradually introduced to Scrum mechanics, accountabilities, and principles, and also to selected core engineering and technical patterns and practices that complement Scrum.
The trainer acts as a product owner by defining or refining requirements before each Sprint and attending Sprint Reviews. By the end of day 3, teams become familiar with all Scrum components and rules: they define and enact Scrum accountabilities (Product Owner, Scrum Master, Developers), work with Scrum artifacts (Product Backlog, Sprint Backlog, Increment), learn how to fulfill commitments to Scrum artifacts (Product Goal, Sprint Goal and the Definition of Done), run all Scrum events (Sprint Planning, Sprint, Daily Scrum, Sprint Review, Sprint Retrospective), refine their backlog, learn about Scrum Values and empiricism, and experience common challenges of working in teams. Selected DevOps technical practices, like estimation techniques, code reviews, continuous delivery, and automated testing, are incorporated as activities during the Sprints for students to understand why and how they perfectly complement Scrum. A class retrospective is done after each Sprint to enforce learning objectives. Discussions are encouraged throughout the entire duration of the course.
The case study is available in different flavors: .Net, .Net Core, Java, Python, PHP, NodeJS, and C++. Since the goal of the course is to learn about Scrum and its synergy with DevOps practices and tools, the student's possibly unaligned technology background does not impede students to actively participate in team exercises. Besides programmatic tasks, there are plenty of other activities to cover, like acting as a Scrum Master, dealing with user requirements, estimating, testing, and triaging bugs, designing a CI/CD pipeline, etc. Public classes have a fixed technology stack and we expect at least part of the students to be comfortable with the case study. For private classes, the trainer works with the team up front to define a specific technology stack that meets their needs.