Professional Scrum Developer .NET

PSD course information

Return to the PSD Programs page.

 

PSD+ Course PSD Course Comparison

 

Course Objectives

Course attendees will learn to:

• Form effective teams
• Explore and understand legacy “Brownfield” architecture
• Define quality attributes, acceptance criteria, and “done”
• Create automated builds
• How to handle software hotfixes
• Verify existence and elimination of bugs
• Plan releases and sprints
• Estimate product backlog items
• Create and manage a sprint backlog
• Hold an effective sprint review
• Improve your process by using Sprit Retrospectives
• Use emergent architecture to avoid technical debt
• Use Test Driven Development as a design tool
• Setup and leverage continuous integration
• Use Test Impact Analysis to decrease testing times
• Use refactoring practices effectively
• Create and manage test plans and cases
• Create, run, record, and play back manual tests
• Setup a branching strategy and branch code
• Write more maintainable code
• Identify and eliminate people and process dysfunctions
• Inspect and improve your team’s software development process

Audience

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

  • architect
  • programmer
  • database developer
  • tester
  • Product Owners, Scrum Masters, and other stakeholders are welcome too. Keep in mind that everyone who attends will be expected to commit to work and pull their weight on the team.

Course at a Glance

This 3-day Professional Scrum Developer .NET 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
Visual Studio Scrum		 Emergent
Architecture
Sprint 1		 Ship It!
Sprint 3
Afternoon Case Study
Planning		 Test-Driven
Development
Sprint 2		 Overcoming
Dysfunction

 

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.


Component Description Minutes per Sprint
Instruction Presentation and demonstration of new and relevant tools & practices 60
Sprint planning meeting Product owner presents backlog; each team commits to delivering functionality 10
Sprint planning meeting Each team determines how to build the functionality 10
The Sprint The team self‐organizes and self‐manages to complete their tasks 120
Sprint review meeting Each team will present their increment of functionality to the other teams <=30
Sprint retrospective A group retrospective meeting will be held to inspect and adapt 10


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 the attendees to get to know the instructors as well as each other. The Professional Scrum Developer program, as well as the day by day agenda, will be explained. Finally, the Scrum team will be selected and assembled so that the forming, storming, norming, and performing can begin.

Module 2: Visual Studio Scrum

This module demonstrates how to implement Scrum in Visual Studio 2010 and Team Foundation Server 2010. The team will learn the mapping between Scrum concepts they already know and how they are implemented in the tool. After connecting to the shared Team Foundation Server, the team members will use Visual Studio to manage a Scrum project.

Module 3: Case Study

In this module the team is introduced to their problem domain for the week. A kickoff meeting hosted by the Product Owner (the instructor) explains the case study and its requirements. This will set the stage for the upcoming Sprints. The team will define the product’s quality attributes and their definition of “done.” The legacy application code will be downloaded, built, and explored, so that any bugs can be discovered, triaged, and effectively reported.

  • Introduction to the case study
  • Download the source code, build, and explore the application
  • Define the product’s quality attributes
  • Define “done”
  • Filing effective bug reports
  • In-Sprint vs. Out-of-Sprint bugs
  • Using Architecture Explorer to visualize and explore
  • Review and Retrospective

Module 4: Planning

This module explains the goals and activities related to creating and managing the Product Backlog and Sprint Backlog. The team will learn the importance of specifying acceptance criteria and estimating effort as well as how and why to groom the Product Backlog, as well as how and why to specify acceptance criteria and estimates.

  • Release planning
  • Grooming the Product Backlog
  • Estimating the Product Backlog items
  • Acceptance criteria
  • Spring Backlog
  • Review and Retrospective

At this point the team will have the knowledge of Scrum, Visual Studio 2010’s support for Scrum, and the case study application to begin developing increments of potentially shippable functionality that meet their definition of “done”.

Module 5: Emergent Architecture

This module introduces the architectural practices and tools a team can use to develop a valid design on which new functionality can emerge. The teams will learn how Scrum and Visual Studio 2010 Ultimate edition encourage and support good architecture and design practices. After the discussion, the team will be presented with the ordered Product Backlog so that they may select, forecast, and commit to the functionality they can deliver in Sprint 1.

  • Architecture and Scrum
  • Emergent architecture
  • Principles, patterns, and practices
  • Visual Studio 2010 modeling tools
  • UML and layer diagrams
  • SPRINT 1
  • Review and Retrospective

Module 6: Test-Driven Development

This module introduces the team to the why, what and how of unit testing in Visual Studio 2010. The team will learn why Continuous Integration (CI) and Test-Driven Development (TDD) are important and how Visual Studio and Team Foundation Server support those activities. Refactoring will also be defined and demonstrated in combination with Visual Studio’s Test Impact Analysis to efficiently re-run just those tests which were impacted during refactoring.

  • What is a unit test and why we care
  • Continuous Integration (CI) using Team Foundation Build
  • Test Driven Development (TDD)
  • Code Coverage, Refactoring, and Test Impact Analysis
  • SPRINT 2
  • Review and Retrospective

At this point the team will have the knowledge of Scrum, Visual Studio 2010, and the case study application to begin developing increments of potentially shippable functionality that meet their definition of done.

Module 7: Ship It

Development teams need to know that just because they like the functionality doesn’t mean the Product Owner or the business will. This module revisits acceptance criteria as it pertains to acceptance testing. By refining acceptance criteria into test cases and manual test steps, team members can execute the tests, record the results, report any bugs, and know when they are done with a particular Product Backlog item. Teams will learn how to create and manage test cases, manual tests, and test runs. As a Sprint completes and an increment of functionality is released, the team will also learn why and when they need to branch the codeline.

  • Acceptance testing in Visual Studio 2010
  • Microsoft Test Manager
  • Test case management
  • Maintaining tests
  • Branching and merging
  • SPRINT 3
  • Review and Retrospective

Module 8: Overcoming Dysfunction

This module introduces the many types of people, process, and tool dysfunctions that a team can face in the real world. Many dysfunctions and scenarios will be identified, along with ideas and discussion for how a team might overcome them. This module will enable you and your team to move toward independence and improve your game of Scrum when you depart class.

  • Becoming a high-performing development team
  • Development team challenges and how to overcome them
  • Flaccid Scrum and ScrumButs
  • Inspecting, adapting, and being transparent
  • Working with challenging Scrum Masters
  • Working with challenging Product Owners and Stakeholders
  • Course Review and Retrospective

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:

All students should have:

* Check with instructor for the exact technologies that will be in use.

People who should not take this course include:

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!