jump to navigation

Notes on Agile Product Ownership in a Nutshell March 9, 2015

Posted by willhlaw in Administrivia, Productivity.
Tags: ,
add a comment

Illustration

Above is an illustration from the video ‘Agile Product Ownership in a Nutshell‘ that uses the RSA animation technique. Below are the notes highlighting key points made during the video as well as some other points drawn from additional resources. This post will be a good read for Product Owners, both new and experienced, as well as any team member on an Agile Scrum team that wants to revisit the basic principles and possibly realign their team.

Roles in Scrum
PO – Product Owner carries the vision, says no or yes to customer requests, prioritizes, and responsible for building the right thing.
SM – Scrum Master is the coach, responsible for building it fast and fast feedback cycles with the users.
Other Roles
TL – Technical Lead is responsible for building the thing right, talks closely with customers and other teams, but still encourages self organization.
CPO – Chief Product Owner organizes multiple POs and interdependencies.
Development Manager hires, mentors engineers, creates culture, and knows when to step in and lead discussion on branching strategy or versioning [1]
Key Points
Product backlog becomes Team backlog when working on multiple products (new products, old products, O&M, etc)
Value = knowledge value + customer value.
Knowledge value is gained early to reduce risk. Knowledge user stories are UI mock ups, trade study, spikes, prototypes, etc.
Stories have an estimate for effort & value so priority = value / effort. This should make it easier for PO to prioritize Team backlog.
Velocity goes down overtime due to technical debt, architecture decisions, getting behind on automated testing. It is the team’s job to correct. However, how is this investment effort tracked? This question is asked and a lot of the sources below were found here.
  1. Be transparent by explaining benefits of paying down technical debt so that PO can prioritize. [4]
  2. Have a separate Improvement backlog that is internal that is adds a tax to each sprint (e.g. 10-20% of velocity). [5] [6]
  3. Do not obsess over it, basically just pick one and fix the broken stuff already [7]. Also, consider adding to the definition of done (DoD) that the work is done only if it does not add any technical debt.
Charts [2]
Time vs customer value curve = knowledge value, customer value focus, trim the tail
Time vs delivered stories
– fixed scope
– fixed time
– fixed scope and time -> no, let’s decrease scope (b/c can always extend time and not the other way around)
Reasons for Scrum:
– team motivation (not overworked, pressure from above, lack of input or control of march)
– deliver value in sweet spot of the triple constraints (time, cost, quality) Venn diagram
– more accurate predictions and expectation management
– standard metrics to evaluate team improvement and tech choices
Points measure effort [3]
Effort should translate to time, and is influenced by uncertainty and complexity.
  1. How much effort to get to that building? Answer for runner and cripple is one.
  2. How much effort to get to farther away bldg? Answer for both is two, since it looks twice as far.
  3. How much effort to get to farther away bldg where there is a chasm of lava and a small walkway? Answer for both finally agree that it is a 4, since they will have to be extra careful and may drastically slow their progress.
  4. How much effort to get to close bldg while singing Gangnam Style? Answer for both finally agree that it is still a 1, as the extra complexity doesn’t really have an effect on the effort that causes a slowdown.
[1] Development managers vs scrum masters, Dan Radigan at Atlasian, https://www.atlassian.com/agile/effective-management-across-agile
[2] Agile Product Ownership in a Nutshell, Henrik Kniberg, Youtube video – https://www.youtube.com/watch?v=502ILHjX9EE, Transcription – http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell
[3] Story Points Are Still About Effort, Mike Cohn at Mountain Goat Software, http://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort
[4] How to translate “business value” of things that are technically important, Matthias Marschall at Agile Web Development & Operations, http://www.agileweboperations.com/how-to-translate-business-value-of-things-that-are-technically-important
[5] Effective Steps to reduce technical debt: An agile approach, Bastian Buch at Codovation, http://www.codovation.com/2012/06/effective-steps-to-reduce-technical-debt-an-agile-approach/
[6] Scrum Strategy – The Dev Team Improvement Backlog, Professional Scrum Trainer at Scrum Crazy, http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Backlog
[7] Do agile right – Delivery – Technical Debt, Atlassian, http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Backlog
Advertisements