Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Unit 5: Planning Releases

Jez Humble
October 02, 2018

Unit 5: Planning Releases

Despite rumours to the contrary, there are planning activities in the agile model. In this class we’ll discuss how to plan releases, and present story mapping and impact mapping as effective tools for design, ideation and planning.

Jez Humble

October 02, 2018

More Decks by Jez Humble

Other Decks in Education


  1. i290 lean/agile product management unit 4: planning releases @jezhumble https://leanagile.pm/

    [email protected] This work © 2015-2020 Jez Humble Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
  2. 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
  3. 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?
  4. 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?
  5. 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…)
  6. 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
  7. 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”
  8. key results are measurable outcomes “objectives and key results” objectives

    are clear statement of goals / intent prioritized gathered from key stakeholders (including teams) OKRs
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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?