The document discusses the State of OpenStack Product Management work group. It was formed in 2014 to improve OpenStack delivery and user experience. The work group gathers requirements, creates user stories, implements specifications with projects, and generates a multi-release community roadmap. It consists of product managers, technologists, operators, and end users from diverse organizations. The work group collects requirements from various groups and perspectives, creates user stories, and works with projects to implement stories through blueprints and specifications. It provides a community roadmap to show direction across over 25 projects.

1. The State of OpenStack
Product Management
Carol Barrett – Intel
Shamail Tahir – IBM
August 24, 2016
All product and company names are trademarks™ or registered®
trademarks of their respective holders. Use of them does not imply any
affiliation with or endorsement by them.

2. Meet The Product Work Group
• Formed at the Paris Summit (2014)
• To improve the quality of the delivery process, the delivered product, and the product
experience for operators and end users, by:
• Gathering Requirements
• Creating common User Stories
• Teaming-up with project teams to create and implement specs/blueprints
• Generating a multi-release Community roadmap
• Consists of product managers, technologists, operators and end-users from a diverse set of
organizations and industries
2

3. 3
Analyze
Design
Implementation &
Test
Document
Maintain, then
Deprecate
Product Lifecycle Model

4. 4
Requirements Vary By Perspective
DIY
Distribution
Managed Private
Cloud
Public Cloud
Enterprise
Telco
HPC
Frequency of releases
Capacity Management
Prefer more frequent releases; upgrades are not an issue and
prefer getting new features/fixes faster
Fine with either slower or faster releases
Prefer less frequent releases due to upgrade processes
Prefer more frequent releases; upgrades are not an issue and
prefer getting new features/fixes faster
Desired but not priority; not seen as blocker
Desired but not priority; relevant but have more focus on
monitoring/troubleshooting currently
High priority item; one of the 4 top priorities outlined by the
Scientific WG
Consumption Models
Market Segments

5. 5
Collecting Requirements
Large
Deployments
Telco
Academic/
Scientific
Monitoring
Upgrades
APIs
Ecosystem
OpenStack
Projects
Industry
Experts
Enterprise
Logging Operators
Meetups
OpenStack
Summits
Market
Segments
Capabilities
Experts
 Gathering requirements from WGs, Operators and others
• User Story template fields includes:
• Problem Definition
• Use Cases (using Personas)
• Usage Scenario Examples
• Requirements
Do we have your requirements?

6. 6
User Story Creation
Market
Segments
Capabilities
Experts
User
Stories
 Gathering requirements from WGs, Operators and others
 Creating common User Stories
Viewable Here
Proposed User
Story
Concept Validation
Template Check
Dashboard for
Community
User Story Tracker
• Rolling Upgrades
• HA VM
• Bare Metal Service
• Capacity Management
• Fleet Management
Priority User Stories
Reviewable Here
Are your use cases included?
HA VM
Rolling
Upgrades
Capacity
Management
Large
Deployments
Telco
Academic/
Scientific
Monitoring
Upgrades
APIs
Ecosystem
OpenStack
Projects
Industry
Experts
Enterprise
Logging Operators
Meetups
OpenStack
Summits

7. 7
Implementing User Stories
• Assess gaps and overlaps
• Define implementation plan and stakeholders
• Integrate with Community development work flow
• PWG User Story owner tracks and reports progress
Implementation Plan
Blueprints
Specs
Code/Status
Gap and Overlap
Analysis
Cross Project Spec
Cross Project Discussions
New Project
1 or more actions
IRC meeting in
#openstack-cp
HA
VM
 Gathering requirements from WGs, Operators and others
 Creating common User Stories
 Teaming-up with project teams to create and implement
specs/blueprints

8. 8
Community Roadmap
* Some projects that are deemed essential but don’t have adoption data are also included (e.g. Oslo, QA, etc.)
• Provides forward-facing information on
direction for over 25 projects*
• Roadmap information updated twice per
release cycle
• Views present information by themes
Form
Design
Series
Team
Conduct
Video
Interviews
Build
Slides,
Validate &
Publish
 Gathering requirements from WGs, Operators
and others
 Creating common User Stories
 Teaming-up with project teams to create and
implement specs/blueprints
 Generating a multi-release Community
Roadmap
Interview
PTLs
Identify
Project
List
Form
Team
Generate
100’, 1K,
10K
Views
Validate
&
Publish
Community
Roadmap
Newton
Design Series
Are the projects and information you need included?

9. 9
Community Roadmap Examples
Newton Design Series

10. Wrap-up
• Our Community wants and values your input
• Together we can develop the best solutions
• There are many ways to get involved
• Bring your requirements to the Community
• Review and help improve User Stories
• Join the Roadmap team to shape which Projects are included
• Keep an eye out for us in Barcelona
• Roadmap session
• Work Group session
10
Wiki Page
Meeting Info and Logs

11. Thank You

12. 12
Product Lifecycle Model: OpenStack Style
Shamail
Analyze
A need is identified based on customer
feedback, direct ops feedback, bug
reports, or user stories.
Design
A spec (or cross project spec) is created
that includes the use case, feature
design details, and how it will be
implemented. A blueprint may also be
created depending on the project.
Implementation/Test
Developers implement the feature and
the code is reviewed by peers in Gerrit.
Tempest tests are also created (if
applicable) for unit testing and CI
(continuous integration) tests also occur
to ensure the change does not break the
service.
Document
The new feature or enhancements
are documented in the relevant
docs (devref, user, admin, etc.)
Maintain
Bug fixes and critical fixes
(including security) are resolved for
impacted features/capabilities.
Deprecate
Once a capability has been
superseded, or is no longer
required, a depreciation plan is
created and implemented by the
development team.