Best Free Scrum Books
- The Scrum guide (recommended)
- Scrum and XP from the trences (recommended)
- Kanban and Scrum - making the most of both
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.
Scrum Framework - Planning - BacklogGrooming - DevOps - AgileTesting - QualityCode - CI - ScrumChallenges - EmergentArchitecture
1. The Scrum Framework
The rules of Scrum, according to the Scrum Guide from the point of view of the Dev Team.
Inspection, adaptation, transparency
Roles, events, artifacts
Empirical process control
Cross functionality, self-organization
Timeboxing
Definition of Done (DoD)
Techniques to track progress (boards, burndowns, burnups, Sprint/release, alternatives)
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 & when to decompose large PBI’s into smaller ones, each PBI must have value)
What Dev Team needs to know in order to assist the PO in creating, clarifying, and estimating items in 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)
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
What the Dev 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
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)
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
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)
Technical approaches to developing software architecture and design that a Dev 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