Professional Scrum Developer Java

PSD course information

Return to the PSD Programs page.

 

PSD+ Course

PSD Course

Comparison

 

Course Objectives

Course attendees will learn about:

Scrum

• Run several, complete Sprints
• Plan the Sprints in Sprint Planning Meetings
• Hold Daily Scrums
• Track progress with burndowns
• Have Sprint Reviews with stakeholders
• Reflect experiences and understandings in Sprint Retrospectives
• Define and work according to a Definition of Done

Agile Best Practices

• Requirements are discussed based on user stories and their acceptance criteria
• Estimating with Story Points and Planning Poker
• The Development Team applies test driven development and test first
• The given code base is full of code smells and needs to be refactored
• Continuous integration is applied
• Development takes place in pairs

Audience

PSD Java is a medium level course. Well-functioning Scrum Teams looking for assistance with advanced topics like scaling Scrum or implementing a rigorous ROI framework will not receive as much benefit from this course. If you are looking to explore more advanced topics, you should consider the Professional Scrum Master course or Product Owner course.

This course is suitable for any member of a software development team:

• Entire project teams already working together and wanting to explore Scrum
• Teams of Developers with Scrum knowledge and experience
• Individual Developers with Scrum knowledge and experience
• Programmers, Architects, Database Developers, Testers etc.
• Product Owners and Product Managers may participate in the course by pairing with a developer and experience Scrum from the developer’s perspective

Course at a Glance

This 3-day Professional Scrum Developer Java course is a mix of lecture, demonstration, group discussion, simulation, and hands-on software development. The bulk of the course will be spent working as a team on a case study application delivering increments of new functionality in mini-sprints. Here is the course at a glance:

	Day 1	Day 2	Day 3
Morning	Introduction, Familiarizing with existing "Brownfield Application," Planning Poker	Sprint Planning Meeting Daily-Scrum Definition of Done	User Stories Test-Driven Development Code smells and refactoring
Afternoon	SPRINT 1 Sprint Review and Retrospective	SPRINT 2 Daily-Scrum Sprint Review and Retrospective	SPRINT 3 Daily-Scrum Review and Retrospective Continuous Integration Outro

 

Note: Scrum fundamentals are not covered in this 3-day course. This course is designed for students who have a solid understanding of Scrum either through working on a Scrum Team or through taking part in a Professional Scrum Foundations course.

Timeboxes

Timeboxing is a critical concept in Scrum as well as in this course. We expect each team and student to understand and obey all of the timeboxes. The timebox duration will always be clearly displayed during each activity. Expect the instructor to enforce it.

Timebox	Usual Timing
Sprint Planning Meeting	1h
Sprint Length	4h
Programming	2h
Daily Scrum	15 min
Sprint Review	30 min
Sprint Retrospective	30 min

Each team is expected to self-organize and manage their own work during the sprint. Pairing is highly encouraged. The instructor/product owner will be available if there are questions or impediments, but will be hands-off by default. You should be prepared to communicate and work with your team members in order to achieve your sprint goal. If you have development-related questions or get stuck, your partner or team should be your first level of support.

Syllabus

Module 1: Introduction

This module provides a chance for attendees to get to know the instructors as well as each others. The Professional Scrum Developer program, as well as the day by day agenda, will be explained. Finally, the Scrum Teams will be selected and assembled so that the forming, storming, norming, and performing can begin.

• Trainer and student introductions
• Scrum.org and the PSD program
• Agenda
• Logistics
• Team formation

Module 2: Familiarizing with the ‘brownfield’ application

This module is intended to get the students hands dirty with the existing ‘brownfield’ DOSBox application. They have to fix a couple of broken tests. Thereby, they have a chance to familiarize with the source code, the existing testing framework and the IDE.

• Project environment
• Source code structure
• Test framework
• Eclipse IDE

Module 3: Planning poker

Planning poker is introduced early: The backlog shall be estimated to measure the team’s velocity.

• Estimation in agile projects
• Absolute versus relative estimation
• Planning poker process
• Common mistakes

Module 4: Sprint, Introduction to Scrum

This module provides a very basic understanding of the Scrum framework including the roles, timeboxes, and artifacts. The team will then experience Scrum firsthand by simulating a mini release with mini sprints of product development, including Sprint Planning, Sprint Review and Sprint Retrospectives meetings.

• Scrum overview
• Scrum roles
• Scrum timeboxes (ceremonies)
• Scrum artifacts
• Motivation for Scrum
• Retrospective

It is required that you read the Scrum Guide in preparation of this module.

Module 5: Sprint Planning Meeting

This module explains what happens during the Sprint Planning Meeting. How the team is enabled to provide a realistic commitment for a set of Product Backlog items, the ‘What’ in the Sprint Planning 1 and how it translates the ‘What’ into ‘How’ during the Sprint Planning 2.

• Agile planning
• Velocity
• Capacity
• Sprint goal
• Sprint planning 1
• Sprint planning 2
• Acceptance criteria

Module 6: Daily Scrum

This module describes in depth the idea behind the Daily Scrum, how it is facilitated and what to watch out for.

• Participants
• The three questions
• Examples and outcome
• Impediments

Module 7: Definition of Done

During this module, the team defines their Definition of Done (DoD). For this they get a short introduction into the different DoD’s.

Module 8: Review and Retrospective

This module describes how to conduct a successful Review. It shows what is important and what the common pitfalls are. The Retrospective part addresses the importance of inspect and adapt on the team level. How the outcome and action items of a retrospective are important for the self-organization of the team.

• Planning a review
• What to do and what is to be avoided
• How to handle feedback
• Inspect and adapt
• Plan – Do – Check – Act from the past into the future
• Techniques for effective retrospectives

Module 9: User Stories, Definition of Done, Planning Poker

This module explains why User Stories are a good for requirements elicitation, why they are no specification and how they can be validated during the sprint. How the Definition of Done relies on the Acceptance Criteria and why a company appropriate Definition of Done is so important.

• Customer value, priority, effort
• Card – Conversation – Confirmation
• INVEST principle
• Inspect and adapt
• Acceptance criteria
• SMART principle
• Definition of done

Module 10: Test Driven Development

This module looks into the history of Pair Programming, why it works and why it makes sense to do it. Testing is easy when a system is testable. Dependency Injection is one great technique to achieve this.

• The cycle of test, code and refactor
• The three laws of TDD
• 3A Pattern (Arrange, Act, Assert)
• Reasons why it is beneficial to do TDD
• Agile testing quadrants

Module 11: Code Smells, Refactoring

This module describes the various kinds of code smells, how they can be eliminated by refactoring; this module includes a life example given by the instructor. Furthermore this module looks into code attributes which make testing easy.

• Types of code smells
• Law of Demeter
• Live refactoring example

Module 12: Continuous Integration

This module looks into the history of continuous integration, why it is important to integrate often. Also, this module explains how continuous integration can be used for more than building and testing, but to enforce company standards and source metrics.

• Continuous integration setup
• Big visual display / eXtreme feedback devices
• Types of build processes
• How it can be rolled-out
• Build artifacts
• Team Behavior

Expectations

This is a unique course in that it’s technically‐focused, team‐based, and employs timeboxes. It demands that the members of the teams self‐organize and self‐manage their own work to collaboratively develop increments of software.

All students must commit to:

• Pay attention to all lectures and demonstrations
• Participate in team and group discussions
• Work collaboratively with other team members
• Obey the timebox for each activity
• Commit to work and do your best to deliver

All students should:

• have a good theoretical understanding and some practice with Scrum (from books, experience, or a Professional Scrum Foundations course)
• have an understanding of the roles of the Scrum Master, Product Owner, and Development Team
• Know the basics of a Sprint, Sprint Planning Meeting, Daily Scrum, Sprint Reivew, and Sprint Retrospective.
• have the knowledge to outline a Sprint Backlog and create a burndown chart
• have read the Scrum Guide
• have taken the Scrum Open assessment
• Have basic programming skills in Java with Eclipse or any other Java IDE
  

People who should not take this course include:

• Students requiring command and control style instruction
• Students who are unwilling to work collaboratively on a team
• Students who don’t have any skill in any of the software development disciplines
• Students who are unable to commit fully to their team – not only will this diminish the student’s learning experience, but it will also impact their team’s learning experience

Note: Product Owners, Scrum Masters, and other stakeholders are welcome to attend this class, so long as they keep in mind that everyone who attends will be expected to commit to work and pull their weight on the team. Also note that this is a technical training class being delivered to teams of developers, not pairs, and not individuals. Ideally, your actual software development team will attend the training to ensure that all necessary skills are covered. However, if you wish to attend an open enrollment course alone or with a few colleagues, realize that you may be placed on a team with other attendees. The instructor will do his or her best to ensure that each team is cross-functional to tackle the case study, but there are no guarantees. You may be required to try a new role, learn a new skill, or pair with somebody unfamiliar to you. This is just good Scrum!