Slide 1

Slide 1 text

i290 lean/agile product management unit 4: planning releases @jezhumble https://leanagile.pm/ humble@berkeley.edu This work © 2015-2020 Jez Humble Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Slide 2

Slide 2 text

know how to mitigate limitations understand what release planning is for be able to perform release planning meet some well-known prioritization tools understand tools for measuring progress learning outcomes

Slide 3

Slide 3 text

focuses on what / why, not how a medium-term plan (1-3 months) done on cadence outcome and user oriented creates shared understanding and alignment among stakeholders what’s a release?

Slide 4

Slide 4 text

a “minimum viable product” the date you ship the software (use CD!) a list of features / backlog / roadmap a commitment to ship a list of features what’s not a release?

Slide 5

Slide 5 text

what goes into a release? Customer requests Architectural changes (performance, reliability, security and so on) Features Support & operational work BAM ! UNPLANNED WORK (defects, discoveries, emergencies…)

Slide 6

Slide 6 text

The Big Question How can we know if we can get the things we want done in the time available? Spoiler: we can’t …and that’s OK

Slide 7

Slide 7 text

how outcomes are delivered is a team decision features/requirements become stale over time ultimately it’s outcomes that matter, not features backlog grooming is a waste and a distraction turning outcomes into work is best done just-in-time “backlog grooming”

Slide 8

Slide 8 text

key results are measurable outcomes “objectives and key results” objectives are clear statement of goals / intent prioritized gathered from key stakeholders (including teams) OKRs

Slide 9

Slide 9 text

use “five whys” to get from features/tasks to KRs distinguish between commitments & aspirational aspirational objectives: aim for 70% success rate update status regularly reject low-value work that doesn’t help OKRs tips and tricks

Slide 10

Slide 10 text

key results A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum

Slide 11

Slide 11 text

capacity planning Leading the Transformation - Gruver, Mouser

Slide 12

Slide 12 text

Epic Theme Story

Slide 13

Slide 13 text

master story list

Slide 14

Slide 14 text

stuff you didn’t know about dependencies stuff you didn’t think about doesn’t actually solve the problem it wasn’t actually what we wanted what could possibly go wrong? mix of skills architecture / non-functional requirements politics cognitive bias

Slide 15

Slide 15 text

planning fallacy Executives tend to “make decisions based on delusional optimism rather than on a rational weighing of gains, losses, and probabilities. They overestimate benefits and underestimate costs. They spin scenarios of success while overlooking the potential for mistakes and miscalculations. As a result, they pursue initiatives that are unlikely to come in on budget or on time or to deliver the expected returns—or even to be completed.” Kahneman, Thinking Fast and Slow, p252.

Slide 16

Slide 16 text

cost “Even in projects with very uncertain development costs, we haven't found that those costs have a significant information value for the investment decision… The single most important unknown is whether the project will be canceled. The next most important variable is utilization of the system, including how quickly the system rolls out and whether some people will use it at all.” Douglas Hubbard | http://www.cio.com/article/119059/The_IT_Measurement_Inversion

Slide 17

Slide 17 text

master story list units?

Slide 18

Slide 18 text

If everything went exactly to plan… It would be extremely embarrassing if we didn’t hit…

Slide 19

Slide 19 text

lightweight planning A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum

Slide 20

Slide 20 text

introducing user story mapping

Slide 21

Slide 21 text

the depth of a map contains variations and alternative tasks tasks are short verb phrases that describe what people do & have different goal levels tasks in a map are arranged in a left-to-right narrative flow you can slice the map to identify the tasks you’ll need to reach a specific outcome. tasks are organized by activities across the top of the map, forming its backbone key points

Slide 22

Slide 22 text

focused on user activities, not business epics holistic view of work, activities, users (context) create a better shared understanding of product dynamically “slice out” coherent releases trade off value / usability / feasability (prioritization) what’s different?