• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Measuring Product Management/Ownership Effectiveness in a Lean/Agile world
 

Measuring Product Management/Ownership Effectiveness in a Lean/Agile world

on

  • 1,857 views

Effective Product Ownership is key to enabling an effective agile delivery. What goals should we set? How would we measure them?

Effective Product Ownership is key to enabling an effective agile delivery. What goals should we set? How would we measure them?

Statistics

Views

Total Views
1,857
Views on SlideShare
1,831
Embed Views
26

Actions

Likes
1
Downloads
13
Comments
1

1 Embed 26

http://yuvalyeret.com 26

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • A note - this presentation is back from 2010 and is due for an overhaul. I'd love to hear what people think about this, but in general there's a lot of thinking from 'Lean Startup' that I would now use to make it better.

    The main guiding principle would be something like 'As those leading the product we want metrics that would show us the leanness/speed/focus/iterative nature of our product discovery processes so that it will help us focus more on faster and faster validated learning loops OVER waterfallish big batches of up front everything-included specifications'

    What do you think?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Measuring Product Management/Ownership Effectiveness in a Lean/Agile world Measuring Product Management/Ownership Effectiveness in a Lean/Agile world Presentation Transcript

    • Metrics for the LEAN/Agile Product Manager Yuval Yeret
    • Main things we want to pay attentionto • Performance of the Production floor – covered elsewhere (Simple KPIs Slides) • Performance of the Product Management group: – Business Value – Wastes related to PM – Technical Debt
    • Business value • We care about outcome – features delivered, adopted, used, paid for • How can we measure this? • Manage a kanban at the high level features level, that tracks when features are adopted, and upon first paying customer. • Then see how much WIP of features not yet adopted we have, LEAd/Cycle time to adoption, features that we dropped on the way.
    • Debt • A lot of time debt is taken due to PM decision • We want to track how much debt we have, and take action to minimize it. • E.g. we need to release ASN1 now, so we don’t “automate tests”/”code it correctly”, so every work on ASN1 is slower, until this is fixed
    • Tracking debt in kanban • Have debt card type that is created when debt is taken on • Track amount of debt versus overall WIP/Backlog • See whether stable, improving, worsening trend • Decide on policy for dealing with debt – WIP Limit, etc. • Track the cycle time and WIP for debt cards to see whether they get the SLA they deserve
    • Wastes related to PM • Waiting for PM • PM related Churn / Context switching / Expediting • Sunk Costs • Rework due to late feedback by PM
    • Waiting for PM • Look at the CFD, observe the size of the PM-related queues over time. – Especially Pending PM Review which is in the middle of DEV/Test – And Ready-MMFs as well as DEV Ready in some cases which depend on PM approval – Advanced – in the cycle time performance report, focus on PM areas • When looking at exceptions to Cycle time, participate in the root cause analysis, and see if interaction with PM was part of the long cycle time.
    • PM related Churn / Context switching /Expediting • Add Expedited class of service – Can be used by PM to override priorities in DEV WIP – just to top of queue, don’t override current WIP • Add emergency class of service – Can also override current WIP • Assumption – – This is value trumps flow. We give up efficiency when we use
    • Measuring the effect of value overflow COS • Look at cycle times for different kinds of classes of service • Look at distribution of different COS in the WIP
    • Look at amount of changes in scope • Replace – need visualization that shows scope changes in content • Add – can simply look at total scope for a “Release” and observe whether its growing
    • Case Study – Typical release behavior 250 Added Growth in Scope Feature Cost / Dark 200 Matter Total Required Work 150 Actual Done Planned Scope Planned Done Original + Dark Matter 100 Linear (Total Required Work) Linear (Original + Dark Matter) 50 0 1 2 3 4 5 6 7 8 9 10
    • • Dark Matter – Is where we thought a feature costs X• But then, during breakdown, analysis, creating iteration stories, we understand it actually costs X+D• Then, PM decides whether to scope to fit down to X again, or D is worth it.• Worthwhile tracking our behaviour on this, and learning from it.• What is the right D number/percent? Good question!• Can be observed in the CFD for a release.
    • Sunk Costs • Add a LANE that collects features/stories that are “ON HOLD” – the Recycle Bin in the archive area • The amount of work done on them is the sunk cost • Amount of work hard to measure, so use alternative: – CYCLE TIME – look at cycle time for end lane being the recycle bin
    • Rework due to late feedback by PM • Will appear as high cycle times • Will appear as moving back cards on the board (need to find way to measure) • Can use special Class of service / card type to identify these kinds of stories better for measurement/tracking purposes
    • Workload compared to DEV • See how much workload is in PM compared to DEV • Look for trends and major changes that can indicate: – Bottleneck in PM – Idle and slack capacity – expect to see PM seeing clients/customers at those times