AI_SCRUM/Essential Scrum - Chapters/27_Index.txt

# Index

### A Absolute sizes, vs. relative sizes in estimation,

125–128 Acceptance criteria

conditions of satisfaction related to

product backlog, 77 defined, 401 definition of ready and, 110 product owner defining and verifying,

169–170 user stories containing confirmation

information, 85–86 Acceptance-test-driven development (ATTD),

85–86, 402 Acceptance tests

conditions of satisfaction expressed via, 85 defined, 401 product owner responsibilities and, 169 verifying conditions of satisfaction, 77 Accountability, of product owner, 173 Accrual of technical debt, managing, 149–152 Accuracy

defined, 402 vs. precision in estimation, 125, 274–275 Actions, resulting from retrospective

deciding what action to take, 389–390 determining possible actions, 387–388 follow through on, 391–392 as output of sprint retrospective, 381 selecting insights to act on, 388 Activities

defined, 402 overview of, 16–18 Adaptation. See also Prediction and adaptation

principle, in agile development balancing predictive work with adaptive

work, 43–44 based on product review, 371

daily scrum as inspect-and-adapt activity,

354 defined, 402 discovering your own path forward, 396 and exploration in approach to

development, 39–40 as focus of planning rather than

conformance, 249–251 leveraging variability, 35–36 plan-driven development compared with

agile development, 59 responsibilities of development team,

197–198 sprint retrospective and, 375 sprint review and, 363 Agile development

concerns about adopting, 225 defined, 402 managers promoting agile values, 233–234 no end state in, 395 overview of, 1–3 plan-driven approach compared with,

59–60 product backlog in, 1 sharing best practices, 396–397 The Agile Manifesto (Beck), xxxi, 30,

204–205, 210 Agile principles

accepting that you can’t get it right up

front, 38–39 adapting to real-time information and

replanning based on, 54 adaptive, exploratory approach, 39–40 balancing predictive work with adaptive

work, 43–44 batch sizes in, 48–49 cost of change and, 40–43 cost of delays and, 52–54

Agile principles (continued )

product backlog as, 18–19 sprint backlog as, 18 Asset teams, 214. See also Component teams Assets

embracing helpful variability, 32–33 focusing on idle work, 51–52 inspection, adaptation, and transparency,

35–36 inventory management, 49–50 iterative and incremental approach to

measuring progress by asset validation,

54–55 monitoring and reports focusing on asset

validation, 236 Assumptions

development, 33–35 keeping options open, 37–38 learning loops in, 45–46 measuring progress by asset validation,

calculating release costs and, 325–326 defined, 402 replanning based on validation of, 251 validated learning and, 45, 304 Atmosphere, setting for sprint retrospective,

54–55 minimizing unnecessary formality, 57–58 organizing workflow for fast feedback,

382 ATTD (Acceptance-test-driven development),

46–47 overview of, 29–32 prediction and adaptation, 37 quality built-in to development process,

85–86, 402 Attendance

sprint retrospective issues, 392 sprint review issues, 372–373 Authority, levels of (Appelo), 230 Automated testing, 149, 355–356

56–57 reducing uncertainty, 36–37 sustainable pace in performance of work, 56 validated learning in, 44–45 value-centric delivery in, 55 variability and uncertainty and, 32 work in process (WIP) and, 48 Agile Retrospectives (Derby and Larsen), 379 All-at-once product development

### B Batch size

in agile development, 48–49 comparing plan-driven development with

defined, 402 in origins of Scrum, 3 All-before-any approach

agile development, 60 defined, 403 Benefits of Scrum, 4–5 Best practices, 396–397 Blame

defined, 402 to work in process, 48 Anticipatory process. See plan-driven

development Appelo, Jurgen, 230 Approach

creating blame-free atmosphere for sprint

retrospective, 382 sprint retrospective issues, 393 “Boil-the-ocean” projects, 65 Boy Scout rule

defined, 402 essential scrum includes, xxix realizing Scrum practices, 13 Artifacts

defined, 403 servicing technical debt when you happen

defined, 402 just-in-time approach to creating work

upon it, 158–159 Budget constraint

products, 43 managing inventory of planning artifacts,

fixed date approach, 313–314 fixed everything approach, 311–312 fixed scope and date approach, 312–313 fixed scope approach, 313 in release planning, 311

251–252 potentially shippable product increment

as, 25–26

Burndown chart

defined, 403 for fixed-scope release, 327–328 sprint, 357–359 Burnup charts

defined, 403 for fixed-scope release, 328–329 sprint, 359–360 Business

engagement pattern with, 170 making technical debt visible at business

level, 153–154 ScrumMaster skills related to business

domain, 188

### C Cadence

benefits of consistent duration of sprints,

67–68 defined, 403 Capacity

defined, 403 in Kanban, 10 measuring in effort-hours, 342–343 measuring in story points, 342 sprint planning, 22, 340–342 underutilization of, 351 Card format, for user stories, 83–84 Ceremony

defined, 403 minimizing unnecessary, 57–58, 368 plan-driven development compared with

agile development, 60 Change

consequences of, 70–71 handling cost of, 40–43 maintaining sprint goals despite, 69–73 managing, 79 overcoming the status quo, 398–399 as product backlog item, 101 Change agent, ScrumMaster as, 187, 191 Chaotic domain

in Cynefin framework, 6–7, 9 defined, 403 Checkpoints, short duration sprints providing

frequent, 66–67

Chickens and pigs, 25, 403 Chief product owner, 183–184, 404 Clarification, of sprint goals, 69–70 Closing retrospectives, 390–391 Closure, timeboxing enforcing, 63 CMMI maturity model, 395 Coach

a day in the life of ScrumMaster, 190 ScrumMaster as, 16, 185–186 Code refactoring. See Refactoring code Cohn, Mike, xxv, xxxiii–xxxiv, 129–130, 206,

395, 397–398 Collaboration

benefits of face-to-face communication, 205 cross-cluster, 240–241 funneling through project manager,

242–243 of product owner with development team,

170–171 of product owner with stakeholders, 171 ScrumMaster skills, 189 in sprint review, 370 Commercial development projects, 177–179 Commercial-off-the-shelf (COTS), 8 Commitment

as basis of sprint goals, 69 change and, 71 checking if realistic, 344–345 defined, 404 of development team, 207–208 estimates contrasted with, 124–125 sporadic attendance and, 372–373 sprint planning outcomes and, 17–18, 346 Communication

channels between teams, 240–241 development team skills/characteristics,

204–205 facilitating shared understanding, 81–82 product owner skills, 172–173 of progress in fixed-date release, 329–330 of progress in fixed-date release planning,

327–329 ScrumMaster skills, 189–190 of sprint execution progress, 356 transparency of, 205–206 Competence, managers developing team

members, 231–232

Complaints, sprint retrospective issues, 393 Complex adaptive systems

planning release of features to customers,

308 product roadmap and, 260 Continuous improvement

defined, 404 flight pattern of geese illustrating, 199 Scrum origins and, 3 Complex domain

no end state in Scrum, 395 sprint retrospective and, 375 while applying iterative and incremental

in Cynefin framework, 6–8 defined, 404 Complexity, Scrum providing confidence in

development, 34 Continuous integration

defined, 404 helping work at a sustainable pace, 209 technical practice, 355 use of good practices prevents accrual of

handling, 6 Complicated domain

in Cynefin framework, 6–8 defined, 404 Component teams

technical debt, 149 Contracts, limitations of fixed-price contracts,

combining with feature teams, 217–218 defined, 404 feature teams compared with, 213–216 product owner for, 177, 180–181 when defining a product, 116 when to use, 216 Components

235 Conversations

in development of user stories, 84–85 facilitating shared understanding, 81–82 Coordination. See also Collaboration

cross-cluster, 240–241 funneling through project manager,

development of, 213–214 development projects, 180–181 integration and testing, 46–47 Conditions of satisfaction, 404. See also

242–243 Cost of delay

Agile principles and, 52–54 comparing plan-driven development with

Acceptance criteria Confidence, acquiring in sprint planning,

agile development, 60 defined, 404 portfolio planning and, 271–274 for properly quantifying technical debt

344–346 Confidence threshold

defined, 404 for product planning, 290, 298 targeting realistic, 300–302 Confirmation information, in user stories,

economics, 150–152 Costs

calculating in release planning process,

325–326 handling cost of change, 40–43 of idle work, 52–53 Scrum reducing, 6 technical debt impacting development

85–86 Conformance to plans, in plan-driven

development, 54, 60, 250 Constraints, in release planning

fixed date, 313–314 fixed everything approach, 311–312 fixed scope, 313 fixed scope and date, 312–313 inputs to sprint planning, 338 overview of, 311 updating, 314 variable quality and, 313–314 Continuous deployment (delivery)

costs, 142–143 COTS (Commercial-off-the-shelf), 8 Cross-cluster collaboration, 240–241 Cross-functional diversity and sufficiency, of

development team, 200–201 Cross-functional teams

in agile development, 2 defined, 405 feature teams, 213

defined, 404

high-bandwidth communication and, 205 managers forming, 228–229 quality built-in to development process,

56–57 vs. role-specific teams, 195–196 Cunningham, Ward

on refactoring, 149 on technical debt, 139–140 Customer satisfaction

Scrum benefits, 6 technical debt decreasing, 144 Customer uncertainty

defined, 405 reducing, 36 Customers

engagement pattern with, 170–171 planning release of features to, 307 product owner understanding needs of, 166 repaying technical debt while performing

customer-valuable work, 160–162 value-centric delivery focused on needs

of, 55 value of user stories to, 90 Cynefin framework

defined, 405 for situation-appropriate decision making,

6–7

### D Daily planning, 258, 264–265 Daily scrum

approaches to, 397 daily planning during, 264–265 defined, 405 sprint execution and, 354 sprints and, 23–25 when grooming occurs and, 108 Daily stand-up. See Daily scrum Date constraint

fixed date approach, 313–314 fixed everything approach, 311–312 fixed scope and date approach, 312–313 fixed scope approach, 313 in release planning, 311 Deadlines, resulting in technical debt,

144–145

Decision making

economic filter for go/no-go decision

making, 275–276 illusion of certainty and, 303 incremental/provisional approach to

funding, 304–305 keeping options open, 37–38, 249 plan-driven development compared with

agile development, 59 by product owner, 173 which work needs to be done, 353–354 which work to start, 352 DEEP (Detailed appropriately, Emergent,

Estimated, and Prioritized) appropriate detail, 101–102 characteristics of good product backlog, 101 defined, 405 emergent nature of, 102 prioritization in, 103–104 size estimates in, 102–103 Defects

compounding, 142 defining when sprint is complete or done

and, 75 as product backlog item, 100–101 as technical debt, 139 Defined process, in plan-driven development,

32 Definition of done

checklist, 74–76 confidence threshold as envisioning, 290 defined, 405 development team needs skills to meet,

200–201 evolving over time, 76–77 for managing technical debt, 149–150 no end state in Scrum, 395 nonfunctional requirements for inclusion

in, 93 overview of, 25–26 preventing accrual of technical debt, 150 versus acceptance criteria, 77 what work needs to be done, 353–354 Definition of ready

acceptance criteria, 169 checklist, 109–110 defined, 405

Definition of ready (continued )

PBI estimation, 123–124 product owner collaborating with, 166,

overview, 108–110 product backlog items for sprint planning,

170–171 responsibilities of, 196–197 role of, 16 role-specific teams, 195–196 rules of Planning Poker and, 132 as Scrum role, 16 self-organizing nature of, 198–200 small size of, 206 sprint planning, 21–23 sustainable pace in performance of work,

336 providing boundaries for work at the task

level, 353 selecting product backlog items and, 344 understanding how to demonstrate items

at sprint review, 370 Delays, cost of. See Cost of delay Delegation, as means of empowering teams,

230 Deliverables. See also Potentially shippable

208–209 T-shaped skills, 201–203 technical practices for task performance,

product increments (PSIs) short duration sprints and, 65–66 technical debt increasing time to delivery,

355–356 transparency of communication, 205–206 when grooming occurs and, 107–108 Discussions

142 Demonstration aspect, of sprint review, 368,

370 Design flaws, as technical debt, 139 Detail

in sprint review, 371 when estimating, 121–122 when writing user stories, 81–82, 85 Disorder domain

in product backlog, 101–102 in user stories, 86–88 Development team

in Cynefin framework, 6–7, 9 defined, 406 Diversity, of development team, 200–201 Documentation

accountability of product owner to, 173 communication skills of, 204–205 cross-functional diversity and sufficiency

conversations compared with, 81–82 cost of delay example involving, 53–54 in definition of done, 74 lack of in VersionOne 2011 survey, 225 plan-driven development as document-

of, 200–201 daily scrum for, 23 defined, 405 focus and commitment of, 207–208 grooming product backlog, 105–106 long-lived nature of, 209–211 multiple teams with one product backlog,

centric process, 57 in Scrum development, 57–58 supplementing user stories, 84 Domain skills, of product owner, 171–172 Done

115–116 Musketeer attitude (all for one, one for all),

203–204 one team with multiple product backlogs,

acceptance criteria compared with, 77 checklist, 74–76 defined, 406 done vs. done done, 77–78 evolution of definition of done over time,

117–118 overview of, 195 participant in product planning, 288–289 participant in release planning, 308 participant in requirements conversation,

76–77 no end state in Scrum, 395 sprint review confirming, 367–368 value of strong definition of done in

84 participant in sprint execution, 348 participant in sprint planning, 335 participant in sprint retrospective, 377 participant in sprint review, 364–365

preventing accrual of technical debt, 149–150

Dot voting

defined, 406 selecting which insights to act on, 388 Duration, of sprints

calculating from estimated size and

measured velocity, 119–120 consistency of, 67–68 short duration preference, 64–67 story points in calculation of, 128

### E Economic filter

defined, 406 for go/no-go decision making, 275–276 Economics

of abnormal sprint termination, 72–73 of aligning all teams to a single product

backlog, 115–116 of change, 70–71 of component teams, 218 of developing a project plan per sprint, 349 focusing on short time horizon in product

planning, 302 improved by fast feedback, 65 incremental/provisional funding, 304–305 learning fast and pivoting as necessary, 305 of long-lived teams, 210 managing, 167–168, 236 marginal economics applied to in-process

products, 283–285 of product planning, 299–300 of release approach, 253 of rising development costs, 142 single versus multiple release, 252–253 of smaller, more frequent releases, 279–280 speed and efficiency and, 302–303 targeting realistic confidence threshold,

300–302 of technical debt, 150–152 validated learning, 303–304 Economies of scale, manufacturing vs.

product development, 48 Effort/cost, scheduling portfolio backlog

items and, 274 Effort hours

capacity in, 342–343

checking if commitment is realistic,

344–345 tasks in, 122 Emergent opportunities

defined, 406 embracing quickly, 278–279 Emotions seismograph

defined, 406 mining for insights, 385 sprint retrospective and, 384–385 Empirical process control (Schwaber and

Beedle), 35, 406 End of life, not repaying technical debt for

products approaching, 157 End uncertainty

defined, 406 reducing uncertainty, 36 Enjoyment, Scrum benefits, 6 Enterprise Transition Community (ETC), 398 Environment, managers’ responsibilities

aligning internal groups, 234 aligning partners, 234–235 promoting agile values, 233–234 removing organizational impediments,

234 Envisioning. See Product planning Epics

defined, 406 estimating, 103 in release train, 221 representing product backlog items,

294–295 size of user stories and, 86–88 story mapping technique and, 96 Errors, setting limit or bound on, 65 Estimable criteria, INVEST, 91–92 Estimation

accuracy vs. precision, 125, 274–275 commitments contrasted with, 124–125 defined, 407 development team in PBI estimation,

123–124 ideal days for measurements in, 128–129 overview of, 119–120 of PBIs, 121 Planning Poker approach, 129–133 of product backlog, 121–122

Estimation (continued )

plan-driven development compared with

product owner and, 175 relative sizes vs. absolute sizes, 125–128 scale in, 130 story points for measurements in, 128 of tasks, 122 units for, 128 what and when of, 120–121 ETC (Enterprise Transition Community), 398 Event timeline

agile development, 59 short duration sprints aiding, 64–65 technical debt and, 139 Fast pace, of development

fast delivery as Scrum benefit, 6 go fast but never hurry, 56 Feature teams

combining with component teams,

217–218 comparing with component teams,

defined, 407 mining for insights, 385 sprint retrospective and, 384 Excitement/enthusiasm, short duration

213–216 defined, 407 product owner, 180-181 Features

sprints rejuvenating, 65–66 Exercises

defined, 407 as product backlog item, 100–101 release flow management and, 110–111 user stories and, 87–88 Feedback. See also Fast feedback

inputs for sprint retrospective, 380 selecting for use in sprint retrospective, 379 Experiments, knowledge-acquisition user

stories, 93 Exploitation, 59, 407 Exploration

in iterative and incremental development,

34–35 learning fast and pivoting as necessary, 305 learning loops and, 45–46 organizing workflow for, 46–47 performance feedback given by managers,

defined, 407 knowledge-acquisition user stories, 93–95 plan-driven development compared with

agile development, 39–40, 59 External stakeholders

232 plan-driven development compared with

defined, 407 product owner collaborating with, 171 Extreme Programming (Beck and Andres),

agile development, 59 in prioritization of iterations, 2 short duration sprints aiding, 64–65 sprint review and, 364–365 Fixed date constraint, in release planning,

355, 407

### F Face-to-face communication, 205 Facilitator

313–314 Fixed-date release

calculating costs in, 325–326 communicating progress of, 329–330 defined, 408 overview of, 318–323 planning and, 67–68 Fixed everything constraint, in release

ScrumMaster as, 16 for sprint execution, 348 for sprint planning, 335–336 for sprint retrospective, 393 for sprint review, 368 Fail fast, 305, 407 Fast feedback. See also Feedback

planning, 311–312 Fixed-price contracts, limitations of, 235 Fixed scope and date constraints, in release

defined, 407 early review and, 367 monitoring and reports aligned to, 236 organizing workflow for, 46–47

planning, 312–313 Fixed scope constraint, in release planning,

Fixed-scope release

calculating costs in, 325–326 communicating progress of, 327–329 defined, 408 planning, 323–325 product roadmap and, 260–261 Flow

daily scrum in management of, 354 deciding which work needs to be done,

353–354 deciding which work to start, 352 defined, 408 managing in sprint execution, 349–350 organizing task work, 352–353 organizing workflow for fast feedback,

46–47 parallel work and swarming, 350–352 release flow management, 110–111 Scrum used in organizing work flow, 3 sprint flow management, 111–112,

349–350 who does the work, 354 Focus

of development team, 207–208 of sprint retrospective, 378–379 Forecasts

defined, 408 terminology choices for sprint planning

outcomes, 17–18 velocity, 135 vs. commitments, 346 Formality

minimizing unnecessary, 57–58 plan-driven development compared with

agile development, 60 unnecessary formality defined, 420 Framework, for Scrum

activities and artifacts, 16–18 closing review, 28 core values, principles, and practices in,

xxix daily scrum, 23–25 defined, 408, 416 overview of, 13 practices, 14 product backlog, 18–20 roles, 14–16 sprint execution, 23

sprint planning, 21–23 sprint results, 25–26 sprint retrospective, 27–28 sprint review, 26–27 sprints, 20–21, 61 Frustration, technical debt resulting in, 144 Functional managers. See Managers Funding, incremental/provisional approach

to, 304–305

### G Gantt chart

sprint execution and, 349 of up-front plan, 250 Go/no-go decision making

economic filter for, 275–276 funding decisions, 299 Goals. See also Sprint goal

managers providing team goals, 228 no end state for, 395 Grenning, James, 129 Grooming

defined, 408 insight backlog, 390 overview of, 104 product backlog, 19, 315 responsibilities of development team, 197 responsibility of product owner, 169 in Scrum framework, 17 ScrumMaster working with product owner

on, 190 what it is, 104–105 when does it occur, 106–108 who does it, 105–106 Groups

compared with teams, 209–210 defined, 408 managers role in aligning internal, 234

### H Happened-upon technical debt, 155, 158–159,

408 Harvesters (Goldberg and Rubin), 217 Hidden agendas, transparency and, 189 Hierarchical product backlogs, for large

products, 114–115

High-bandwidth communication, devel-

Inflow strategies, portfolio planning

opment team skills/characteristics, 204–205 Hiring/firing authority, of managers, 229

balancing product flow into/out of

portfolio backlog, 276–278 economic filter for go/no-go decision

making, 275–276 embracing emergent opportunities,

### I Ideal days

278–279 overview of, 275 small, frequent releases, 279–280 Information radiator. See also

defined, 408 measuring magnitude of PBI, 128–129 as relative size measures, 20 Ideal hours

Communication defined, 409 elements of, 356 Innovation accounting

defined, 408 task estimated in, 122 Ideation, 288 Idle work

defined, 409 metrics in, 236–237 Innovation waste, 90, 409 Insight backlog

comparing plan-driven development with

agile development, 60 defined, 409 focusing on idle work not idle workers,

defined, 409 grooming, 390 inputs for sprint retrospective, 381 as source of insights, 386 Insight cards, 386–387 Insights, in sprint retrospective

51–52, 281 monitoring and reports focusing on, 236 Idle workers, 51–52, 281, 409 Impediments

identifying, 385–387 inputs for sprint retrospective, 381 insight backlog, 390 selecting among, 388–389 Inspection

defined, 409 managers removing, 234 ScrumMaster removing, 187, 191 Implementable stories

defined, 409 size of user stories and, 87 story mapping technique and, 97 In-process products

daily scrum as inspect-and-adapt activity,

354 defined, 409–410 discovering your own path forward, 396 leveraging variability, 35–36 planning based in inspection and

defined, 409 marginal economics applied to, 283–285 overview of, 283 portfolio planning and, 268 Incremental approach, to servicing technical

adaptation, 248 responsibilities of development team,

197–198 sprint retrospective and, 375 sprint review and, 363 Integration

debt, 159 Incremental development

agile principles underlying Scrum, 33–35 defined, 409 short duration sprints rejuvenating

of components, 46–47 continuous integration practice, 149, 404 defined, 410 of improvement actions, 391 release train approach (Leffingwell) and,

participant excitement, 65 Incremental funding

defined, 409 economics of product planning, 304–305 Independent criteria, INVEST, 88–89

Integration management, technical debt and,

140 Integration tests, 75 Interference shield, ScrumMaster as, 187 Internal development projects, choosing

product owner for, 176–177 Internal stakeholders

defined, 410 product owner collaborating with, 171 Internationalization, testing in definition of

done, 75 Interrupt-driven work, Scrum not suited for,

9–10 Inventory

defined, 410 managing in agile development, 49–50 managing planning artifacts, 251–252 plan-driven development compared with

agile development, 60 INVEST criteria, for user stories

defined, 410 estimable, 91–92 independent, 88–89 negotiable, 89–90 overview of, 88 sized appropriately, 92 testable, 92 valuable, 90–91 Investment, change impacting, 70–71 Iterative development

in agile development, 2–3 agile principles underlying Scrum, 33–35 defined, 410

### J Jeffries, Ron, xxvii–xxviii, xxxiv, 83 JIT (just in time). See Just in time (JIT) Just enough

appropriate detail in product backlog, 101 of predictive planning, 300 requirements and, 79 Just in time (JIT)

appropriate detail in product backlog, 101 balancing predictive work with adaptive

work, 43–44 balancing up-front planning with just-in-

time planning, 248

creating work products, 43 defined, 410 keeping options open, 249 requirements and, 79 sprint planning, 335

### K Kanban

defined, 410 development process suited for interrupt

driven work, 9–10 Katz, Ralph, 210 Kerth, Norm, 375, 379 Knowledge acquisition

as product backlog item, 100–101 sprint for, 298 user stories, 93–95 Knowledgeable, ScrumMaster skills, 188 Known technical debt

defined, 410 repaying incrementally, 159 repaying while performing customer-

valuable work, 160–161 servicing, 155–156

### L Last responsible moment (LRM) (Poppen-

dieck and Poppendieck) defined, 411 keeping options open, 37 Leadership

managers providing in functional areas,

232–233 product owner role, 15 Learning

discovering your own path forward, 396 economics of product planning, 305 fast learning combined with pivoting,

254–255 managers role in development of

competence, 231–232 Learning loops

aligning performance feedback to, 232 concurrency of, 45–46 defined, 411 Leffingwell, Dean, 272

Lifecycle profits

Measures (metrics)

defined, 411 impact of cost of delay on, 54 optimizing scheduling for lifecycle

of capacity, 342–343 managers monitoring, 236–237 Mess (Martin), terminology for technical

profitability, 270–271 Longer-term planning. See Release planning LRM (last responsible moment) (Poppendieck

debt, 140 Milestone-driven planning. See Release

planning Milestones, in short duration sprints, 66–67 Minimum marketable features (MMFs). See

and Poppendieck) defined, 411 keeping options open, 37

Minimum releasable features (MRFs) Minimum releasable features (MRFs)

baseline values for actionable metrics, 2

### M Man-hours, task estimated in, 122 Managers

37 defined, 411 defining product roadmap and, 295–296 determining in release planning, 309–310,

aligning internal groups, 234 aligning partners, 234–235 changing team composition, 229 defining team boundaries, 227 developing team member competence,

320 marginal economics applied to in-process

products, 284 refining, 316 Minimum viable product (MVP). See

231–232 empowering teams, 230–231 energizing team members, 231 fashioning teams, 226 forming teams, 228–229 maintaining team integrity, 233 managing economics, 236 monitoring measures and reports, 236–237 overview of, 225–226 participating in sprint retrospective, 377 project management responsibilities,

Minimum releasable features (MRFs) MMFs (minimum marketable features). See

Minimum releasable features (MRFs) Monitoring measures and reports, managers,

236–237 Motivation

managers role in energizing people, 231 product owner skills, 173 MRFs (Minimum releasable features). See

Minimum releasable features (MRFs) Multilevel planning

237–239 promoting agile values, 233–234 providing leadership in functional areas,

daily planning, 264–265 overview of, 257–258 portfolio planning, 259 product planning, 259–261 release planning, 261–263 sprint planning, 263 Multiple teams

232–233 providing team goals, 228 removing organizational impediments,

234 systems perspective of, 235 when to retain separate project manager

coordinating using release train approach,

220–223 coordinating using scrum of scrums,

role, 239–243 Manufacturing. See Product manufacturing Marginal economics, applied to in-process

218–220 Multitasking, cost of, 350–351 Musketeer attitude (all for one, one for all)

products, 283–285 Maturity models, not part of Scrum, 395 Means uncertainty

defined, 411 development team skills/characteristics,

defined, 411 reducing uncertainty, 36

203–204

Must-have features

defined, 411 defining product roadmap and, 295 determining in release planning, 320 in focusing on short time horizon, 302 release flow management and, 110–111 MVP (Minimum viable product). See

Minimum releasable features (MRFs)

### N Naive technical debt, 140, 412 Negotiable criteria, INVEST, 89–90 New products

portfolio planning. See Portfolio planning product planning. See Product planning Nice-to-have features

defined, 412 release flow management and, 110–111 release planning, 314, 320 Nonaka, Ikujiro, 3 Nonfunctional requirements, 93, 412

### O Objective data

gathering for sprint retrospective, 379 inputs for sprint retrospective, 380 One-part approach, to sprint planning,

339–340 One-product-one-product-backlog rule

large products and, 114–115 multiple teams and, 115–116 what is a product and, 113–114 Opportunities, embracing emergent

opportunities quickly, 278–279 Options, keeping options open, 37–38, 249 Ordered, terminology for product backlog

sequences, 20 Organizational impediments. See

Impediments Outflow strategies, portfolio planning

establishing WIP limits, 281–282 focusing on idle work not idle workers,

281 overview of, 280 waiting until entire team is in place,

282–283

Outsourcing

choosing product owner for outsourced

projects, 180 limitations of fixed-price contracts, 235 Overtime, impact on quality and velocity,

136–137

### P Parallel work, sprint execution and, 350–352 Participants

in portfolio planning, 268 in product planning, 288–289 in release planning, 308 in sprint execution, 348 in sprint planning, 335–336 in sprint retrospective, 377–378 in sprint review, 364–365 Partners, managers aligning, 234–235 Path forward

discovering, 396 no end state in Scrum, 395 overcoming the status quo, 398–399 sharing best practices, 396–397 using Scrum to discover, 397–398 Patience, ScrumMaster skills, 189 Patton, Jeff, 96 PBI estimation

accuracy vs. precision in, 125 contrasting estimates with commitments,

124–125 development team in, 123–124 overview of, 121–122 Planning Poker approach to, 129–130 relative sizes vs. absolute sizes, 125–128 units for, 128–129 PBIs (product backlog items). See Product

backlog items (PBIs) People skills, of product owner, 172–173 Perfectionism, avoiding unnecessary, 63 Performance

definition of done and, 75 definition of ready and, 110 feedback given by managers, 232 technical debt resulting in

underperformance, 143 Performance principle, in agile development

minimizing unnecessary formality, 57–58

Performance principle, in agile development

types of, 29 variability not accounted for in, 35 Planning

(continued ) overview of, 56 quality built-in to development process,

accepting that you can’t get it right up

56–57 sustainable pace in performance of work,

front, 38–39 adapting to real-time information, 54 consistent duration of sprints simplifying,

56 Person-hours, task estimated in, 122 Personas (roles)

67–68 daily planning, 264–265 a day in the life of product owner, 175 multilevel approach to, 257–258 portfolio planning. See Portfolio planning product owner participating in, 168–169 product planning. See Product planning release planning. See Release planning short duration sprints aiding, 64 sprint execution, 349 sprint planning. See Sprint planning sprints, 21–23 Planning Poker

defined, 412 in user stories, 96 Pichler, Roman, 101 Pigs and chickens, 25, 412 Pipeline of requirements, product backlog as,

112 Pivoting

defined, 412 economics of product planning, 305 envisioning, 288–289 innovation accounting, 237 marginal economics applied to in-process

defined, 412 how to play, 131–133 overview of, 129–130 scale in assigning estimates, 130 Planning principles

products, 283–284 planning and, 254–255 Placeholders

product backlog items (PBIs) as

emphasis on small, frequent releases,

requirements placeholder, 80–81 user stories marking exploration work, 94 Plan-driven development

252–254 focus on adapting and replanning rather

than conforming, 249–251 keeping options open, 249 learning fast and pivoting as necessary,

agile principles compared with, 59–60 all-before-any approach to work in

process, 48 assumptions in, 45 beliefs regarding, 30 costs of change in, 43 defined, 412 defined process in, 32 as high-ceremony approach, 57 integration and testing components in,

254–255 managing inventory of planning artifacts,

251–252 not assuming up-front plans are right, 248 overview of, 247–248 up-front planning should be helpful not

excessive, 248–249 Platforms

46–47 limitations regarding re-planning, 54 linear approach to uncertainty in, 36 phase orientation vs. customer

lack of experience resulting in technical

debt, 140 testing in definition of done, 75 PMI (Project Management Institute), 237–239 Point inflation, 138, 412 Pollinators (Goldberg and Rubin), 217 Portfolio backlog

expectations, 54–55 requirements in, 79 risks related to up front planning, 38–39 sequential approach compared with agile’s

defined, 413

exploratory approach, 39–40

estimating, 121 inflow strategies, 275–280 outflow strategies, 280–283 portfolio planning and, 267, 269 in-process strategies, 283–285 release train approach (Leffingwell), 221 Portfolio planning

balancing product flow into/out of

portfolio backlog, 276–278 calculating cost of delays, 271–274 defined, 413 economic filter for go/no-go decision

making, 275–276 embracing emergent opportunities,

278–279 establishing WIP limits, 281–282 estimating for accuracy not precision,

274–275 focusing on idle work not idle workers, 281 managing economics of, 236 marginal economics applied to in-process

products, 283–285 in multilevel planning, 259 optimizing scheduling for lifecycle

profitability, 270–271 overview of, 267 participants in, 268 planning level details for, 258 process of, 268–270 product owner participating in, 168 small, frequent releases in, 279–280 strategies for in-process products, 283 strategies for inflow, 275 strategies for outflow, 280 strategies for sequence of products, 270 timing of, 267 waiting until entire team is in place, 282–283 Potentially shippable product increments (PSIs)

defined, 413 defining when sprint is complete or done,

74–78 as input to sprint review, 368–369 inspecting and adapting during sprint

review, 363 as outcome of iterative process, 2–3 planning release of features to customers,

release train approach (Leffingwell) and,

220, 222–223 sprint results, 25–26 Practices

activities. See Activities artifacts. See Artifacts defined, 413 roles. See Roles rules. See Rules in Scrum framework, 14 Pragmatism

no-goal-altering-change rule and, 72 Pragmatic Marketing Framework, 178–179 Precision

defined, 413 vs. accuracy in estimating, 125, 274–275 Prediction

balancing predictive work with adaptive

work, 43–44 just enough predictive planning, 300 plan-driven development compared with

agile development, 59 technical debt decreasing predictability,

143 timeboxing improving predictability, 64 Prediction and adaptation principle, in agile

development accepting that you can’t get it right up

front, 38–39 adaptive, exploratory approach in, 39–40 balancing predictive work with adaptive

work, 43–44 handling cost of change, 40–43 keeping options open, 37–38 overview of, 37 pivoting and, 254–255 Predictive process. See Plan-driven

development Prescriptive process. See Plan-driven

development Principle of least astonishment

defined, 413 transparency of communication and, 206 Principles. See Agile principles Prioritization

in product backlog, 103–104 sporadic attendance and, 372–373

Prioritization (continued )

defined, 413 definition of ready, 109–110 emergent nature of, 102 estimating. See PBI estimation grooming tasks related to, 104–105 mapping to sprints, 316–318 measuring velocity and, 133 organizing task work, 352–353 overview of, 100–101 parallel work and swarming, 350 as placeholders for requirements, 80–81 prioritizing, 103–104 representing technical debt, 155 selecting in sprint planning, 343–344 sign-offs and, 372 size estimates, 102–103 user stories adding detailed items, 315 Product development

terminology choices for product backlog

sequences, 20 timeboxing enforcing, 62 Process authority, ScrumMaster as, 186–187 Process-centric development, 60 Process structure, 59 Product backlog

in agile development, 1–2 appropriate detail in, 101–102 conditions of satisfaction, 77 creating high-level list in product planning

process, 294–295 deciding which and how many to form,

112–113 defined, 413 definition of ready, 108–110 determining what is a product, 113–114 economics, 168 emergent nature of, 102 estimating, 121–122 grooming, 104–108, 369, 413 as input to sprint planning, 337 large products with hierarchical backlogs,

benefits of Scrum for, 10 calculating duration from estimated size

and measure velocity, 119–120 defined, 413 economies of scale, 48 focusing on idle work not idle workers,

51–52 inventory management, 50 vs. product manufacturing, 32–33 Product manufacturing

114–115 mapping to releases, 263 multiple teams with one product backlog,

115–116 one team with multiple product backlogs,

comparing plan-driven development with

agile development, 59 economies of scale, 48 inventory management, 49–50 vs. product development, 32–33 Product owner

117–118 overview of, 99 PBIs in, 100–101 prioritization in, 103–104 product owner responsible for grooming,

accountability of, 173 chief product owner, 183–184 collaborating with development team,

169 product planning and, 259–260 release flow management, 110–111 release planning and, 320–321 representing technical debt, 155 in Scrum framework, 18–20 size estimates in, 102–103 sprint flow management, 111–112 sprint planning and, 17, 21–23 Product backlog items (PBIs)

170–171 collaborating with stakeholders, 171 combining with other roles, 181–182 for commercial development, 177–179 for component development, 180–181 creating/verifying acceptance criteria,

169–170 a day in the life of, 174–176 deciding if work is done, 367 decision making by, 173 defined, 414

appropriate detail, 101–102 creating high-level list in product planning

process, 294–295 deciding which work to start, 352

domain skills of, 171–172 function relative to estimation process, 123 grooming product backlog, 105–106, 169 for internal development, 176–177 managing economics, 167–168 for outsourced development, 180 overview of, 165–166 in overview of Scrum roles, 15–16 participant in product planning, 288–289 participant in product portfolio, 268 participant in requirements conversation, 84 participant in sprint execution, 348 participant in sprint planning, 335 participant in sprint retrospective, 377 participant in sprint review, 364–365 people skills of, 172–173 planning functions of, 168–169 principal responsibilities of, 166 proxy product owner, 183 rules of Planning Poker, 132 in sprint planning, 21–22 team approach to, 182–183 understanding value of technical stories,

90–91 who should fill this role, 176 Product owner proxy, 183, 414 Product planning

creating product backlog, 294–295 a day in the life of product owner, 175 defined, 414 defining product roadmap, 295–297 economic filter for go/no-go decision

making, 275–276 economic sensibility in, 299–300 incremental/provisional funding in,

304–305 learning fast and pivoting as necessary, 305 in multilevel planning, 259 new product example, 290–291 other types of work in, 298–299 overview of, 287 participants in, 288–289 planning level details for, 258 process of, 290 product backlog and, 259–260 product owner participating in, 168–169 product roadmap and, 260–261 product vision, 259, 291–294

short time horizon as focus of, 302 speed and efficiency of, 302–303 targeting realistic confidence threshold,

300–302 timing of, 287–288 validated learning in, 303–304 Product roadmap

defining, 295–297 definition of, 414 product planning and, 260–261 release planning and, 262–263 Product vision. See Vision Productivity, multiple projects and, 207 Products

atrophy of appeal due to technical debt,

143 defined, 413 determining what is a product, 113–114 development team responsible to inspect

and adapt, 197 large products with hierarchical backlogs,

114–115 not repaying technical debt for products

nearing end of life, 157 not repaying technical debt for products

with short life, 157–158 planning new. See Product planning portfolio of new. See Portfolio planning Program backlog, 221 Progress

communicating in fixed-date release,

329–330 communicating in fixed-scope release, 327 comparing plan-driven development with

agile development, 60 of sprint execution, 356 timeboxing demonstrating, 62–63 Progress principle, in agile development

adapting to real-time information and

replanning based on, 54 measuring progress by validating working

assets, 54–55 overview of, 54 value-centric delivery in, 55 Progressive refinement strategy

applying to requirements, 82 defined, 414 level of detail, 86

Project chartering, 299, 414. See also Product

Reckless debt (Fowler), 140 Refactoring code

planning Project inception, 299. See also Product

defined, 414 as means of paying down technical debt,

planning Project initiation, 299. See also Product

141 use of good practices prevents accrual of

planning Project Management Institute (PMI), 237–239 Project managers. See also Managers

technical debt, 149 Reinertsen, Donald G.

responsibilities of, 237–239 when to retain separate project manager

on batch-size issues, 48–49 on cost of delay, 53 on lifecycle profits, 270 Relative size measures

role, 239–243 Project Retrospectives (Kerth), 375, 379 Proof of concept, 93 Prototypes

in cost evaluation, 20 defined, 415 vs. absolute sizes in estimation, 125–128 Release goal

knowledge-acquisition user stories, 93 not repaying technical debt for throwaway

prototypes, 157 PSIs. See Potentially shippable product

communicating progress using burndown

chart, 327–328 communicating progress using burnup

increments (PSIs)

chart, 359 defined, 415 economics of, 167 grooming product backlog and, 315 product roadmap and, 296 Release planning

### Q Quality

building in to development process, 56–57 comparing plan-driven development with

agile development, 60 influenced by long-lived teams, 210 overtime and, 137 pressure to meet a deadline affects, 144–148 reduced due to working on too many items

calculating costs in, 325–326 communicating progress in fixed-date

release, 329–330 communicating progress in fixed-scope

release, 327–329 constraints on release, 311 a day in the life of product owner, 175 defined, 415 defining product roadmap and, 296 emphasis on small, frequent releases,

in parallel, 350–351 release constraints, 311 team diversity leads to, 201 traditional project management

responsibility, 238 variability due to constraints, 313–314 Questioning ability, ScrumMaster skills,

188–189 Queue

defined, 414 impact of utilization on queue size (delay),

52–53 portfolio backlog and, 280

### R Range of velocity, calculating, 134–135 Real-time information, adapting to and

planning level details for, 258 process of, 309–311 refining MRFs, 316 sprint mapping, 316–318 technical debt and, 140 timing of, 308–309 updated plan as output of sprint review,

369 updating constraints, 314 variable quality constraint, 313–314 velocity and, 133 Release train (Leffingwell)

coordinating multiple teams using,

220–223 defined, 415 Releases

defined, 415 small, frequent releases in portfolio

planning, 279–280 Replanning, as focus of planning rather than

conformance, 249–251 Reports, managers monitoring, 236–237 Requirements

card format for user stories, 83–84 confirmation information in user stories,

85–86 conversations facilitating shared

understanding, 81–82 conversations in development of user

stories, 84–85 estimatable criteria for user stories, 91–92 gathering user stories, 95 independent criteria for user stories, 88–89 INVEST criteria applied to user stories, 88 knowledge-acquisition user stories, 93–95 level of detail in user stories, 86–88 negotiable criteria for user stories, 89–90 nonfunctional, 93 overview of, 79–80 placeholders for, 80–81 progressive refinement of, 82 sized appropriately criteria for user stories,

Responsibilities, of development team,

groom the product backlog, 197 inspect and adapt each day, 197 inspect and adapt the product and process,

197 perform sprint execution, 196 plan the sprint, 197 Responsibilities, of product owner

collaborating with development team,

170–171 collaborating with stakeholders, 171 creating/verifying acceptance criteria,

169–170 grooming product backlog, 169 managing economics, 167–168 participating in planning, 168–169 Responsibilities, of ScrumMaster,

change agent, 187 coach, 185 impediment remover, 187 interference shield, 187 process authority, 186–187 servant leader, 186 Retrospectives, 375. See also Sprint

retrospective Return on investment (ROI)

cost of delays and, 271–272 responsibility of product owner for

ensuring, 168 Scrum benefits, 6 short duration sprints improving, 65 small, frequent releases improving, 252,

254 Ries, Eric, 44, 157, 236, 254–255 Risk

associated with setting the confidence

threshold, 301 assumptions and, 45 defined, 415 of fixed-price contracts, 180 of misinterpretation using ideal days,

128–129 small batch sizes reduce, 49 traditional project management

responsibility, 238 Roadmap. See Product roadmap ROI. See Return on investment (ROI) Role-specific teams, compared with cross-

Roles

Schedules

combining product owner with other,

attendance issues and, 392 benefit of small batch sizes on, 49 predictable Scrum activities, 68 for sprint review, 366–367 Scheduling strategies, portfolio planning

181–182 combining ScrumMaster with other,

192–193 defined, 415 development team, 16 overview of, 14–15 product owner, 15–16 ScrumMaster, 16 Roles (personas), in user stories, 96 Rolling lookup-ahead planning (Cohn), 318 Rules

calculating cost of delays, 271–274 estimating for accuracy not precision,

274–275 optimizing for lifecycle profitability,

270–271 overview of, 270 Schwaber, Ken, xxix–xxx, 3 Scope constraint

allocate-up-to-ten-percent-capacity-for-

grooming rule, 106 avoid-technical-debt-specific-sprints rule,

fixed date approach, 313–314 fixed everything approach, 311–312 fixed scope and date approach, 312–313 fixed scope approach, 313 in release planning, 311 Scrum framework. See Framework, for Scrum “The Scrum Guide” (Sutherland and

159 Boy Scout rule, 158–159, 403 consistent-duration sprints rule, 67 defined, 415 development-team-should-be-between-

five-and-nine-people rule, 206 development-team-should-be-long-lived

Schwaber), xxix–xxx Scrum introduction

rule, 210 involve-all-team-members-in-story-

benefits to Genomica, 4–5 benefits to organizations, 5–7 Cynefin framework and, 6–10 framework overview, 13–14 origins of, 3 what it is, 1–3 Scrum of scrums (SoS)

writing rule, 294 no-goal-altering-change rule, 20, 72 one-hour-per-sprint-week rule, 367 one-product-one-product-backlog rule,

114–116 people-who-do-the-work-provide-the-

for coordinating multiple teams, 206,

estimates rule, 123 Scrum practices, 14 start-only-what-you-can-finish rule, 344 tasks-should-be-no-more-than-eight-

218–220 defined, 416 Scrum team

defined, 416 development team. See Development team product owner role. See Product owner roles of, 14–15 ScrumMaster. See ScrumMaster ScrumMaster

hours rule, 338 teams-should-handle-their-own-

coordination rule, 239–240

### S Safety, setting atmosphere for sprint

retrospective, 382 Scale

in assigning estimates, 130 multiple small teams vs. single large team,

in overview of Scrum roles, 16 participant in product planning, 288–289 participant in sprint execution, 348 participant in sprint planning, 335–336 participant in sprint retrospective, 377 participant in sprint review, 364–365 responsibilities of, 185–187 scrum of scrums and, 219 skills of, 188–190 in sprint planning, 21–22 sprint retrospective issues, 393 who should fill this role, 191–192 Scrummerfall, 34, 421 Self-fulfilling prophecy, 41–42 Self-organization

defined, 416 by development team, 198–200 sprint execution, 348 undermining, 231 Sequential development. See Plan-driven

development Servant leader

defined, 416 ScrumMaster as servant leader of Scrum

team, 186 Servicing technical debt

Boy Scout rule for, 158–159 incrementally, 159 overview of, 155–156 paying high-interest debt first, 160 reasons for not repaying, 157–158 while performing customer-valuable work,

160–162 Shared context

creating for sprint retrospective, 382–384 emotions seismograph as aid in creating,

384–385 event timeline as aid in creating, 384 mining for insights, 385 Shippable product. See Potentially shippable

product increments (PSIs) Sign-offs, sprint review issues, 372 Silent grouping exercise

for clustering insights, 386 defined, 416 Simple domain

Six Sigma, 8 Size

in cost evaluation related to product

backlog, 20 estimates, 102–103 Skills

inputs to sprint planning, 338 managers role in development of

competence, 231–232 of product owner, 171–173 of ScrumMaster, 188–190 technical practices for task performance,

355–356 Small criteria, INVEST, 92 Small teams

favored for Scrum development, 206 high-bandwidth communication and, 205 SMEs (Subject matter experts), 169 Software development, issues related to, 5 Solutions

benefits of Scrum for, 4 defined, 417 faster and better, 201 innovative, 32 Specialists, on development team, 202 Specification by example, 85, 417 Spikes, knowledge-acquisition user stories, 93 Sprint backlog

defined, 417 estimating, 122 as input to sprint review, 368–369 sprint planning and, 264 Sprint burndown chart, 357–359 Sprint burnup chart, 359–360 Sprint demo, 368, 370, 417 Sprint execution

communicating progress of, 356 daily scrum and, 354 deciding which work to start, 352 determining which work needs to be done,

Sprint execution (continued )

defining focus of, 378–379 determining actions, 387–388 emotions seismograph in, 384–385 event timeline in, 384 follow through on, 391–392 gathering objective data, 379 identifying insights, 385–387 insight backlog, 390 issues related to, 392–393 overview of, 27–28, 375–377 participants in, 377–378 prework needed for, 378 responsibilities of development team, 197 selecting among insights, 388–389 selecting exercises for use in, 379 setting atmosphere for, 382 structuring, 380 Sprint review

sprint burndown chart and, 357–359 sprint burnup chart and, 359–360 task board and, 356–357 technical practices for task performance,

355–356 timing of, 347 who does the work, 354 Sprint goal

defined, 417 inputs to sprint planning, 338 inputs to sprint review, 368–369 maintaining despite changes, 69–73 refining, 346 selecting product backlog items that align

with, 343–344 setting in planning process, 21 Sprint maps, in release planning, 310, 316–318 Sprint planning

adapting based on, 371 approach to, 368–369 attendance issues, 372–373 confirming sprint work is done, 367–368 defined, 418 demonstration aspect of, 370 determining facilitator for, 368 determining who to invite, 366 discussions in, 371 for large development projects, 373 overview of, 26–27, 363–364 participants in, 364–365 preparing for demonstration, 368 prework needed for, 365–366 responsibilities of development team, 197 scheduling, 366–367 sign-offs, 372 summarization of sprint goal and sprint

acquiring confidence, 344–346 a day in the life of product owner, 175 defined, 417 determining capacity in, 340–343 finalizing commitment, 346 managing economics of, 168 in multilevel planning, 263 one-part approach to, 339–340 overview of, 21–23, 335 participants in, 335–336 planning level details for, 258 process of, 336–338 product owner participating in, 169 refining sprint goal, 346 responsibilities of development team, 197 selecting product backlog items, 343–344 terminology choices for sprint planning

results, 369–370 when grooming occurs and, 108 Sprintable stories

outcomes, 17–18 timing of, 335 two-part approach to, 338–339 Sprint results. See Potentially shippable

defined, 417 size of user stories and, 87 story mapping technique and, 96 Sprints

product increments (PSIs) Sprint retrospective

approach to, 380–382 closing the retrospective, 390 creating shared context for, 382–384 deciding among actions, 389–390 defined, 417

abnormal termination of, 72–73 consistent duration of, 67–68 daily scrum and, 23–25 defined, 417

defining when complete or done, 74–78 iterative and incremental approach to

development, 34 maintaining sprint goals despite changes,

69–73 organizing product planning into, 298 overview of, 20–21, 61–62 in Scrum framework, 17 short duration of, 64–67 timeboxing, 62–64 Staats, Bradley R., 210 Stakeholder value

areas of, 292–294 defined, 418 Stakeholders

accountability of product owner to, 173 defined, 418 defining product backlog, 18 getting feedback in agile development, 2 participant in grooming product backlog,

105–106 participant in product planning, 288–289 participant in portfolio planning, 268 participant in release planning, 308 as participant in requirements

conversation, 84 participant in sprint retrospective, 377 participant in sprint review, 364–365 product owner collaborating with, 166, 171 Start/end dates. See Timeboxing Start-only-what-you-can-finish rule, 344 Stories. See User stories Story mapping technique (Patton), 96–98, 418 Story points

defined, 418 measuring capacity in, 342 measuring magnitude of PBI, 128 Planning Poker, 129-133 as relative size measures, 20 Strategic filters

defined, 418 economic filters, 275–276, 406 Strategic technical debt, 140, 418 Strategy planning, 257 Subject matter experts (SMEs), 169 Subjective data, communicating in sprint

retrospective, 383 Subsystem teams, 214. See also Component

Succeeding with Agile (Cohn), xxv, 397 Summarization aspect, of sprint review,

369–370 Sustainable pace

defined, 418 of development team in performance of

work, 56, 208–209 Sutherland, Jeff, xxix–xxx, 3 Swarming

defined, 418 sprint execution and, 351–352 T-shaped skills, 201–203 Synchronization

defined, 418 of multiple teams, 220, 222 System

system-level constraints expressed via

nonfunctional requirements, 93 system-level focus in sprint retrospective,

385 testing in definition of done, 75 Systems perspective, of managers, 235

### T T-shaped skills

choosing who does the work and, 354 defined, 420 diversity of development team and,

201–203 finding balance in utilization of, 351 Tacit knowledge

defined, 419 of technical debt, 154 Takeuchi, Hirotaka, 3 Targeted technical debt

defined, 419 servicing, 155 Task board

for communicating sprint execution

progress, 356–357 defined, 419 Tasks

defined, 419 during sprint planning, 22 estimating sprint backlog, 122 organizing task work, 352–353 technical practices for performance of,

TDD (test-driven development), 378, 419–420 Team structures

overview of, 139–141 reasons for not repaying, 157–158 repaying high-interest debt first, 160 repaying incrementally, 159 repaying while performing customer-

coordinating multiple teams using release

train approach (Leffingwell), 220–223 coordinating multiple teams using scrum

of scrums, 218–220 feature teams vs. component teams,

valuable work, 160–162 servicing, 155–156 variable quality and, 314 Technical knowledge, ScrumMaster skills, 188 Technical practices

213–218 multiple team coordination, 218 overview of, 213 Teams

defined, 419 for task performance, 355–356 use of good practices prevents accrual of

compared with groups, 209–210 coordinating multiple, 218–220 cross-functional. See Cross-functional

technical debt, 149 Technical stories

teams defined, 419 development. See Development team product owner as, 182–183 swarming, 351 unit of capacity, 233, 282 use complete and engaged, 282–283 Teams, fashioning

defined, 419 value of, 90 Technical work, as product backlog item,

100–101 Test-driven development (TDD), 378, 419–420 Test-first development, 353, 420 Testable criteria, INVEST, 92 Testing

changing team composition, 229 defining team boundaries, 227 empowering teams, 230–231 forming teams, 228–229 overview of, 226 providing team goals, 228 Teams, nurturing

automated testing, 355–356 components, 46–47 excessive manual testing resulting in

technical debt, 139 myth that reduced testing can accelerate

velocity, 145–147 quality built-in to development process,

developing team member competence,

56–57 release train approach (Leffingwell) and, 222 types of tests, 75 Themes

231–232 energizing team members, 231 maintaining team integrity, 233 providing leadership in functional areas,

defined, 420 story mapping technique and, 96 user stories and, 87–88 Time-management

232–233 Technical debt

Boy Scout rule for servicing, 158–159 causes of, 144–148 consequences of, 141–144 defined, 419 definition of done and, 76 economics of, 150–152 making visible at business level, 153–154 making visible at technical level, 154–155 making visible with balance sheet, 153-154 managing, 148 managing accrual of, 149–150

act quickly, 302–303 focusing on short time horizon in product

planning, 302 timeboxing for, 62 Timeboxing

benefits of, 62–64 defined, 420 sprint retrospective and, 379 start and end dates, 20–21

Timeline, creating event timeline for sprint

retrospective, 384 Timing

of portfolio planning, 267 of product planning, 287–288 of release planning, 308–309 of sprint execution, 347 of sprint planning, 335 Traditional development process. See Plan-

driven development Training

a day in the life of ScrumMaster, 190 managers role in development of

competence, 231–232 Transparency

defined, 420 of development team, 205–206 leveraging variability, 35–36 of ScrumMaster, 189–190 Trust, managers role in establishing, 231 Two-part approach, to sprint planning,

338–339

### U Unavoidable technical debt, 140, 420 Uncertainty. See also Variability

comparing plan-driven development with

agile development, 59 flow management and, 110 reducing, 36–37 type of, 36 Underutilization, of capacity, 351 Unintentional debt (McConnell), 140 Unit tests, 75 Units, for estimating product backlog items

ideal days, 128–129 story points, 128 Unknown unknowns

defined, 420 uncertainty and, 37 Unnecessary formality. See Formality Unpredictable tipping point, characteristics of

technical debt, 142 Up-front plans

accepting that you can’t get it right up

front, 38–39

focus on adapting and replanning rather

than conforming, 249–251 focus on making helpful not excessive,

248–249 just enough predictive planning, 300 not assuming they are right, 248 User role

defined, 420 user stories and, 83, 96 User stories. See also Requirements

benefits of, 79 card format for, 83–84 confirmation information in, 85–86 conversations in development of, 84–85 defined, 421 detailed product backlog items resulting

from, 315, 320 estimable criteria for, 91–92 gathering, 95 independent criteria for, 88–89 INVEST criteria applied to, 88 knowledge-acquisition stories, 93–95 level of detail in, 86–88 negotiable criteria for, 89–90 nonfunctional requirements expressed

via, 93 overview of, 83 for representing product backlog items,

294–295 sized appropriately criteria for, 92 story mapping techniques, 96–98 testable criteria for, 92 valuable criteria for, 90–91 workshop for writing, 95–96 Utilization, relationship to queue size (delay),

### V Validated learning

concurrent learning loops in, 45–46 defined, 421 organizing workflow for fast feedback,

46–47 overview of, 44–45 product planning and, 303–304 validating important assumptions, 45

Validation, measuring progress by asset

creating shared, 291–292 defined, 414 formats for, 292–293 product planning (envisioning) and, 259

validation, 54–55 Valuable criteria, INVEST, 90–91 Value-centric delivery, 55, 60 Value-creation flow, managers role in

managing economics, 236 monitoring measures and reports, 236–237 systems perspective of, 235 Value-delivery-focused thinking, 353 Values

### W Waste

defined, 421 innovation waste, 90 Waterfall development. See also Plan-driven

defined, 421 in Scrum framework, 13 Variability

development defined, 421 disadvantage of applying to sprint

defined, 421 embracing helpful variability, 32–33 inspection, adaptation, and transparency,

execution, 351–352 error of overlaying Scrum on, 34 Scrum compared with, 5 types of plan-driven approaches, 29 WaterScrum, 34, 422 Weighted shortest job first (WSJF)

35–36 iterative and incremental approach to

development, 33–35 overview of, 32 reducing uncertainty, 36–37 Velocity, of work

defined, 422 scheduling strategies and, 271 Won’t-have features

affecting, 135–137 calculating range of, 134–135 decreasing as technical debt increases, 147 defined, 421 fixed-scope-release burndown chart, 327 forecasting, 135 inputs to sprint planning, 337 misuse of, 137–138 myth that reduced testing can accelerate

defined, 422 release flow management and, 110–111 Work in process (WIP)

batch sizes in, 48–49 comparing plan-driven development with

agile development, 60 considering cost of delays, 52–54 defined, 422 establishing WIP limits, 281–282 inventory management, 49–50 Kanban and, 10 overview of, 48 participants in sprint execution, 51–52 timeboxing setting limit on, 62 Workflow, organizing for fast feedback,

velocity, 145–147 overview of, 119–120 pressure to accelerate resulting in technical

debt, 145 technical debt increasing time to delivery,

142 using predicted velocity to check if

commitment is realistic, 344–345 what it is, 133–134 Vision

46–47 Workshop, for writing user stories, 95–96 WSJF (Weighted shortest job first)

basing on areas of stakeholder value,

defined, 422 scheduling strategies and, 271

293–294