List of Figures
Figure 1.1 Agile development overview
Figure 2.5 Product backlog grooming
Figure 2.6 Product backlog item sizes
Figure 2.7 Sprint characteristics
Figure 2.12 Sprint results (potentially shippable product increment)
Figure 2.14 Sprint retrospective
Figure 3.2 Categorization of principles
Figure 3.4 Scrum uses iterative and incremental development.
Figure 3.5 Scrum process model
Figure 3.6 Make decisions at the last responsible moment.
Figure 3.7 Plan-driven requirements acquisition relative to product knowledge
Figure 3.8 Historical cost of exploration
Figure 3.9 Significant late cost of change with sequential development
Figure 3.10 Self-fulfilling prophecy
Figure 3.11 Flattening the cost-of-change curve
Figure 3.12 Balancing predictive and adaptive work
Figure 3.13 Learning loop pattern
Figure 3.14 Component integration
Figure 3.15 How utilization affects queue size (delay)
Figure 3.16 Deliver high-value features sooner.
Figure 4.1 Sprints are the skeleton of the Scrum framework.
Figure 4.2 The benefits of timeboxing
Figure 4.3 The benefits of short-duration sprints
Figure 4.4 Excitement over time
Figure 4.5 Checkpoint comparison
Figure 4.6 Cumulative investment at different states
Figure 4.7 Deciding on the next sprint length after sprint termination
Figure 5.1 Scrum uses placeholders for requirements.
Figure 5.2 A user story template and card
Figure 5.3 User story with additional data attached
Figure 5.4 User story conditions of satisfaction
Figure 5.5 User story abstraction hierarchy
Figure 5.8 Highly dependent stories
Figure 5.9 Example technical story
Figure 5.10 Undesirable technical story
Figure 5.11 Nonfunctional requirements
Figure 5.12 Knowledge-acquisition story
Figure 6.1 The product backlog is at the heart of the Scrum framework.
Figure 6.2 Product backlog items
Figure 6.3 Product backlog items are different sizes.
Figure 6.4 Product backlog items are estimated.
Figure 6.5 Product backlog items are prioritized.
Figure 6.6 Grooming reshapes the product backlog.
Figure 6.7 Grooming is a collaborative effort.
Figure 6.8 Outside-of-primary-flow grooming with sequential projects
Figure 6.9 When grooming happens
Figure 6.10 Definition of ready
Figure 6.11 Release-level view of the product backlog
Figure 6.12 The product backlog as a pipeline of requirements
Figure 6.13 The product backlog is associated with the product.
Figure 6.14 Hierarchical product backlogs
Figure 6.15 Team-specific view of the product backlog
Figure 6.16 Scenarios for multiple product backlogs
Figure 7.1 The relationship among size, velocity, and duration
Figure 7.2 What and when we estimate
Figure 7.3 Product backlog item estimating concepts
Figure 7.4 The full Scrum team participates in estimation.
Figure 7.5 Effect of committing on estimates
Figure 7.6 Effort versus accuracy when estimating
Figure 7.7 Relative size estimation
Figure 7.8 Absolute versus relative size estimation
Figure 7.9 Planning Poker concepts
Figure 7.10 Planning Poker uses binning.
Figure 7.11 Innolution Planning Poker cards
Figure 7.12 Calculating and using a velocity range
Figure 7.13 A team’s velocity over time
Figure 7.14 The effect of overtime on velocity (based on a figure from Cook 2008)
Figure 8.1 Consequences of technical debt
Figure 8.2 Cost-of-change curve affected by technical debt
Figure 8.3 Pressure to meet a deadline can lead to technical debt.
Figure 8.4 Accruing technical debt to meet unreasonable fixed scope and date
Figure 8.5 The myth, reality, and good practice of how testing affects velocity
Figure 8.6 As technical debt increases, velocity decreases.
Figure 8.7 Activities for managing technical debt
Figure 8.8 Example technical debt economic analysis
Figure 8.9 Ways to make technical debt visible at the technical level
Figure 8.10 Approaches for servicing technical debt
Figure 8.11 A technique for managing technical debt when using Scrum
Figure 9.1 The product owner faces two directions simultaneously.
Figure 9.2 Principal product owner responsibilities
Figure 9.3 The product owner manages economics.
Figure 9.4 Comparison of customer or business engagement over time
Figure 9.5 Product owner characteristics
Figure 9.6 A day in the life of a product owner
Figure 9.7 Example of a product owner on internal development
Figure 9.8 Example of a product owner on commercial development
Figure 9.9 Pragmatic Marketing framework
Figure 9.10 Example of a product owner on outsourced development
Figure 9.11 Example of a product owner on component development
Figure 9.12 Same person as product owner of more than one Scrum team
Figure 9.13 Hierarchical product owner role
Figure 10.1 Principal ScrumMaster responsibilities
Figure 10.2 ScrumMaster characteristics
Figure 10.3 A day in the life of a ScrumMaster
Figure 10.4 Same person as ScrumMaster of more than one team
Figure 11.1 Development team responsibilities with respect to Scrum activities
Figure 11.2 Development team characteristics
Figure 11.3 Flocking isn’t the result of top-down planning.
Figure 11.4 Flocking: simple rules and frequent feedback
Figure 11.7 Team members must act as if they are all in the same boat.
Figure 11.8 The cost of multitasking
Figure 11.9 Sustainable pace over time
Figure 12.1 One product and multiple component teams
Figure 12.2 Two products and multiple component teams
Figure 12.3 Combined feature team and component teams
Figure 12.5 Release train structure
Figure 13.1 Greatest concerns about adopting agile
Figure 13.2 Functional manager responsibilities in a Scrum organization
Figure 13.3 Managers define the boundaries.
Figure 13.4 Functional managers collectively create Scrum teams.
Figure 13.5 Teams rarely have fully connected communication channels.
Figure 13.6 Teams frequently form collaboration clusters.
Figure 13.7 Funneling coordination through a project or program manager
Figure 13.8 Project manager on complex, multiparty development
Figure 14.1 Scrum planning principles
Figure 14.2 Big up-front Gantt chart
Figure 14.3 When the map and the terrain don’t agree, believe the terrain.
Figure 14.4 Single-release economics
Figure 14.5 Multi-release economics
Figure 15.1 Different levels of planning
Figure 15.2 Scrum Alliance website product roadmap
Figure 15.3 A release line in the product backlog
Figure 15.4 Product roadmap releases mapped to the product backlog
Figure 15.5 A release can encompass one or more sprints.
Figure 15.6 Each sprint has a sprint backlog.
Figure 15.7 Hierarchical Scrum planning
Figure 16.1 Portfolio-planning activity
Figure 16.2 Portfolio-planning strategies
Figure 16.3 Cost-of-delay profiles
Figure 16.4 Applying the economic filter
Figure 16.5 Balancing inflow and outflow in the portfolio backlog
Figure 16.6 The value of many emergent opportunities decays rapidly.
Figure 16.7 Large products in the portfolio backlog create a convoy.
Figure 16.8 Teams are the unit of capacity for establishing the product WIP limit.
Figure 16.9 In-process product decision flow based on marginal economics
Figure 17.1 Envisioning is an ongoing activity.
Figure 17.2 Envisioning (product-planning) activity
Figure 17.3 Areas of stakeholder value
Figure 17.4 Fixed, periodic releases
Figure 17.5 SmartReview4You product roadmap
Figure 17.6 SR4U knowledge-acquisition sprint storyboard
Figure 17.7 Guidelines for economically sensible envisioning
Figure 17.8 Consequences of setting the confidence threshold bar too high
Figure 17.9 Decision making under the illusion of certainty
Figure 17.10 Incremental/provisional funding
Figure 18.1 Different release cadences
Figure 18.2 When release planning happens
Figure 18.3 Release-planning activity
Figure 18.4 Fixed date and fixed scope playing a game of chicken
Figure 18.5 Mapping product backlog items to sprints
Figure 18.6 Sprint calendar for SR4U Release 1.0
Figure 18.7 Product backlog ready for release planning
Figure 18.8 Determining the range of features on a fixed-date release
Figure 18.9 Location of must-have features relative to the range of deliverable features
Figure 18.10 Results of fixed-scope planning
Figure 18.11 Fixed-scope-release burndown chart
Figure 18.12 Fixed-scope-release burnup chart
Figure 18.13 Variable-scope-release burnup chart
Figure 18.14 Fixed-date-release burnup chart (with inverted product backlog)
Figure 19.1 When sprint planning happens
Figure 19.2 Sprint-planning activity
Figure 19.3 Two-part sprint-planning approach
Figure 19.4 One-part sprint-planning approach
Figure 19.5 Development team capacity in a sprint
Figure 19.6 Sprint backlog showing PBIs and task plan
Figure 20.1 When sprint execution happens
Figure 20.2 Sprint execution activity
Figure 20.3 Cost of multitasking
Figure 20.4 Mini waterfall during sprint execution—a bad idea
Figure 20.5 Subset of Extreme Programming technical practices
Figure 20.6 Example task board
Figure 20.7 Sprint burndown chart
Figure 20.8 Sprint burndown chart with trend lines
Figure 20.9 Sprint burnup chart
Figure 21.1 When the sprint review happens
Figure 21.2 Sprint review prework
Figure 21.3 Sprint review activity
Figure 22.1 Edward Bear illustrating the need for a retrospective
Figure 22.2 When the sprint retrospective happens
Figure 22.3 Sprint retrospective prework
Figure 22.4 Sprint retrospective activity
Figure 22.5 Aligning perspectives to create a shared context
Figure 22.6 Sprint event timeline
Figure 22.7 Emotions seismograph
Figure 22.8 Retrospective insight card wall
Figure 22.9 Insight cards clustered into similarity groups
Figure 22.10 Insight cards placed into predetermined groups