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.

Transcript

1. 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.
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. key results A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum
11. capacity planning Leading the Transformation - Gruver, Mouser
12. Epic Theme Story
13. master story list
14. 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
15. 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.
16. 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
17. master story list units?
18. If everything went exactly to plan… It would be extremely embarrassing if we didn’t hit…
19. lightweight planning A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum
20. introducing user story mapping
21. 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
22. 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?