PSD Objective Domain

A Professional Scrum Developer has a knowledge of Scrum and is able to work effectively on a Development Team within the Scrum framework while delivering value in the form of working software. This outline lists those general and specific things a certified Professional Scrum Developer knows.

Many of the books and resources apply to multiple topics, not just the ones under which they appear (DRY).

1. The Scrum Framework

The rules of Scrum, according to the Scrum Guide from the point of view of the Development Team, along with some common approaches and patterns to working within the framework.

• Inspection, adaptation, transparency
• Roles, events, artifacts
• Empirical process control
• Cross functionality, self-organization
• Timeboxing
• Definition of Done (DoD)
• Techniques to track progress (Scrum boards, burndowns, burnups, Sprint- and release-level, alternative techniques)

The Development Team’s responsibilities and activities during each type of planning.

• Release planning (date target vs. feature target)
• Sprint Planning (inputs, outputs, forecasting, Sprint Backlog)
• Daily Scrums
• Computing and using Velocity
• Sprint Goal (purpose, creating effective goals)
• Decomposing PBIs (epics, how and when to decompose large PBI’s into smaller ones, each PBI must have value)

3. Product Backlog Grooming

What the Development Team needs to know in order to assist the Product Owner in creating, clarifying, and estimating items in the Product Backlog.

• Basics (why frequent grooming is important, who grooms and when)
• Creating good PBIs (3 Cs - Card, Conversation, and Confirmation)
• Acceptance criteria (SMART, acceptance tests, criteria = test specifications, BDD/ATDD)
• Capturing non-functional requirements
• Avoiding waste in requirements (what vs. how, level of requirements, latest responsible moment)
• Estimation (as a group, relative, story points, Planning Poker technique, estimation wall technique)

4. Application Lifecycle Management (ALM)

What a Scrum Development Team must know about ALM, without regard to any particular tool or technology.

• Tracking work (purpose, progress toward daily-Sprint-release plan, backlogs, boards, traceability, history)
• Version control (SCM basics, version control basics, benefits, branching, merging, strategies)
• Automated builds (purpose, types, testing, CI, CD, strategies)
• Test and deployment (acceptance testing environment, “test lab”)
• DevOps (ALM doesn’t end with a build, deployment, workflows, monitoring, bugs/feedback)

Article: Continuous Integration by Martin Fowler

5. Agile Testing

What the Development Team needs to know about the various types of testing, such as when it occurs, who performs it, and what are the objectives of those tests.

• Who tests when (throughout the Sprint and not at the end, No testers – only developers)
• Done includes tested
• Types of tests and their objectives (e.g. agile testing quadrant)
• Who develops, maintains, and runs the different types of tests.
• Developer testing (unit vs. integration tests)
• Test-Driven Development (what is test first , ATDD, benefits, behaviors, objections)
• Code coverage (usage, myths)
• xUnit basics
• Acceptance testing (Who does that, when and how)
• Exploratory testing (purpose, basics)
• Handling bugs (value of fixing vs. managing, in-Sprint, out-of-Sprint, urgent)
• Practices for fixing bugs (create failing test, fix, refactor, re-test, etc.)
• Maintaining tests, clean tests, basic test smells

6. Quality Code

The Contemporary software development coding practices used by high-performance Scrum Development Teams.

• What is good and what is bad code? Why good code goes bad.
• Technical debt
• Healthy code (standards, code analysis, code metrics, code duplication)
• Techniques for good code (pair programming, code reviews, collective code ownership)
• Refactoring (smells, refactorings, goals)
• Clean Code
• Principles, patterns, practices (SOLID, DRY, YAGNI, separation of concerns, DI-Dependency Injection)

7. Continuous Improvement

The healthy habits and behaviors of high-performance Scrum Development Teams including the ability to identify (smell) dysfunctional and wasteful practices.

• Avoiding flaccid Scrum
• Sprint Retrospective commitments
• Increasing scope of DoD
• Specialists vs. generalists
• Effective collaboration
• Working as a team (collectively fail/succeed, collective code ownership, etc.)
• Collocated vs. distributed (occasionally remote, offshore teams)
• Productivity techniques (Scrum room, interruptions, pair programming vs. code review, …)
• Meeting techniques (Sprint Planning, Review, Retrospective, Daily Scrum, non-Scrum)
• Transparency (honesty, trust)
• Assessing progress (Scrum.org’s assessment, PSD, others)

8. Scrum Challenges

Understanding and mitigating the common challenges and dysfunctions affecting a Scrum Development Team.

• Not getting done (cutting quality, not showing working software at Sprint Review)
• Renegotiating scope (impact, canceling a Sprint)
• Handling undone work (techniques, branching, feature toggles)
• Handling spikes (experiments, proof-of-concepts, learning)
• Handling technical debt (defined, minimizing, removing)
• Handling impediments
• Working at a sustainable pace
• Large PBIs (splitting, each PBI must have value, no “infrastructure” or “architecture” Sprints)
• Changing Scrum (ScrumAnd, formerly known as ScrumBut)
• Dysfunctions (absent PO, working independently, missing meetings, “not my job”, hero)
• Dysfunctions (no collaboration, shared resource, finished early, no energy, no transparency)
• Dysfunction (SM acting as a PM, not done – but close, gold plating, no Product Backlog)

9. Emergent Architecture

Technical approaches to developing software architecture and design that a Development Team must do in order to deliver business value in the form of working software every Sprint.

• Architecture and design are ongoing development activities
• Fit for purpose solutions vs. “gold plating”
• Minimal requirements (up-front design = waste, no BDUF)
• Emergent architecture (defined, thin slicing, slices vs. layers, splitting PBIs)
• Brown vs. greenfield (legacy code, code without automated regression tests)
• Proper use of documentation (models, diagrams, UML, whiteboards)
• Diagrams are for today, rather than a concrete model of where we currently think we want to end up