• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Summary of Todd Olson's Presentation

Page history last edited by Simon Kingaby 7 years, 12 months ago Saved with comment

August 2012 Meeting Guest:  Todd Olson, VP Products, Rally Software Development

 

Todd is responsible for Product Management (incl. marketing, product development, etc.)  One of his roles is to be the manager of the Product Owners.  He is heavily involved in their Agile development process.

 

Some of the Key Points from his presentation include:

 

  • We need to align with the rest of the organization.  
  • 62% of features are rarely or never used.  Obviously, we are not building a lot of value in those features.
  • Talk to the Stakeholders.  Where are there queues?  Put emphasis on reducing the number and depth of the queues.
  • Executive level stakeholders are the most interested in getting business value, but it is exceedingly hard to measure at that level.

 

There are three levels of alignment:

  1. Executive level:  Themes, Initiatives, Programs.  3-6 months time frame.
  2. Features, Minimum Marketable Feature*, Project.  4-6 weeks.
  3. Stories, PBI's, WorkItems.  1 week.

* What is the minimum necessary to show this feature to a user and have them see its value?

 

Workflow statuses:

  1. Themes: Define, Business Case, Balancing, Approval, In-Progress, Enablement
  2. Features:  Idea, Analysis, Ready to Pull, In Dev, Ready to Release, Released, Communicated
  3. Stories:  Backlog, Ready to Pull, In Progress, Accepted, Released

 

  • When you ship a feature, users need to know what they're getting.  Tell them.
  • If we ship more frequently, is ops ready to handle the extra demand for their services?  Can we automate some or all of that process?
  • Themes are most directly aligned with corporate strategy.
  • When defining themes:  Customer Inquiry leads to Problem Statement then make sure to Align with Strategy.  If it doesn't fit the strategy, why are we doing it?
  • Making a Business Case:  Value, Cost/Size, Pricing/Packaging, Competition, Key Features, Training, New Opportunities, Regulation
  • Collecting Evidence of value delivered:  Know what is used; know business value; setup a feedback loop.
  • At the Story level:  Does it work?
  • At the Feature level:  Is it used?
  • At the Theme level: Are we getting the value?
  • Theme - Feature - Story = Why - How - What
  • Get feedback:  Story: Daily - Scrum Team, Feature: Weekly - Product Owners, Theme: Monthly - Everyone
  • At the Theme level, Monthly planning meeting with Kill-Commit-Transform Analysis.  i.e. Kill the theme, commit to the theme for another month, transform the theme and commit to the transformed theme for another month.
  • Features:  Must have, should have, could have.   
  • Use T-Shirt Sizes to estimate features.  These convert to a Feature Points value.
  • Learn how many feature points you can deliver in a month.  Know the cost of your team for a month.  = $avg. cost per feature point.
  • Break things down.  Can this theme/feature/story be smaller?
  • "If you don't have an economic model for building software, you're doing all the wrong things."
  • At the theme level: Value = 1.User/Business Value + 2.Time Value (i.e. this is needed by the trade show or it is worthless) + 3.Risk Reduction / Opportunity Enablement
  • Value:  Why you're doing what you're doing.
  • Table Stakes => Do I need this theme/feature just to play the game?  If so, get it done quick and cheap.  Then focus on the differentiators (Must be awesome, spend money here) and spoilers (neutralize a competitors differentiators).

 

 

Comments (0)

You don't have permission to comment on this page.