Creating a Product

Vision

BLUEAGILITY
Empower the Enterprise
 Bonnie Davison
Process Architect and Agile Transformation Coach
SPC

Join me: linkedin.com/in/bonniedavison

858-414-5836
[email protected]

BLUEAGILITY
Empower the Enterprise
Agenda

Working Introductions Goals Create Visions

Agreements

3
Delivering Value

“Using fast decision cycles to succeed under

conditions of uncertainty and to create value.”
Business and
Architectural “An iterative, incremental and disciplined
approach to product development which
Value emphasizes people, results, collaboration and
responsiveness and it transcends mere
practices and techniques.”

4
What are we building, enhancing and creating?

§  What is the name of your Product?

§  Will you work on another Product in the next 6 months? Year?
§  Do we have everyone we need in the room to discuss our Product?

5
Start with Shared Vision (Product Vision) - The Elevator Test

Start with a verbal description, keep it simple and

include the Business Value.
§  Represent the future and write the vision as such.
§  Anyone off the street should be able to
understand the vision. It can range from a Example:
sentence or to a small paragraph with emphasis Uniform planning and execution
on small. process for delivery of software
§  Vision statements differ from mission solutions that is efficient, repeatable,
statements. and emphasizes tight collaboration
§  While a vision statement is the “Where we between business and IT, all
want to be in xx time?” the mission supported by technology and
statement is the “How we are going to get metrics to make us a premiere world
there?” class organization.
§  Inputs into the Vision statement may include:
§  Current chief pain points
§  Business drivers
§  Client expectations of the future state “When Planning and Executing the Team will
§  Understanding of how the Business/IT validate they are aligned to the Product Vision.”
Process should work (DevOps)
§  Architectural drivers
6
Highly Detailed Product Vision Template

Business and Architectural Leaders may need to provide a more detailed Vision first.
§  A template problem statement that addresses the following is one way to identify the Vision: Who
receives the benefit, Business need, Solution, Why it works, and How this makes us different
Component Type of Informa/on Sample

For [Customer benefit] -> use this in the summary

..of priori/za/on, approval, and management of soEware projects that include costs,
Who [Statement of business need] – the problem
quality, and /me to value…
Requires a uniform standardized PorPolio & Program Management (PPM) Solu/on
The [Summary of XXX solu/on] – the answer (future state)
enabled by process and technology
common discipline of Project Management in a consistent, repeatable way backed by
Is a [Jus/fica/on of solu/on] – why this is good
technology to increase project visibility

Increase overall ROI by showing visibility into:

• Project Comple/on Status

That will [Statement of benefit] – could be a business or IT benefit • Resource U/liza/on Management for shared resources across projects

• Highest value projects that maximizes customer benefits

Increase comple/on percentage of projects started each year by 50%

Today, where it’s difficult to understand capacity using empirical and quan/fiable
Unlike [Summary of current state applicable to the problem] – what they do now
metrics for resource alloca/on
…solu/on enables a common view into the capacity of the organiza/on to take on
Our [XXX Solu/on roadmap to value] – state what value this will bring
work, see bo_lenecks, and iden/fy opportuni/es to organize resources

7
Creating a Product Vision
How we use the Vision
to implement work

8
Minimum Viable Product (MVP)
Create a “Minimum Viable Product” by focusing on the highest value items first

45% Never 64%

Rarely or never used
19% Rarely Predictive Planning
with Waterfall
16% Sometimes execution processes

Focus us on an MVP 13% Often 20%

•  AdapEve Requirements
•  Feedback loops Often or always
•  Empirical planning
% of Features and 7% Always used
Functions Used in a Typical
System*
Empirical Planning
9
Planning is continuous starting with the end in mind

Vision

Roadmap Business
Agility

Program Increment
Planning

Sprint Planning
Project or

Team
Daily Planning Agility

10
Work Progressively Becomes Smaller

Epic or Initiative Epic or Initiative

product needed which will take months to deliver; group
of features
Feature
Feature
service within a product that fulfill user needs User story

User Story
A slice of functionality which should take less than a Task Task
sprint to complete the work; promise of a future
conversation; written from the end-users perspective
Task Task
Tasks
pieces of discreet work the team will do in order to
deliver the user story, 8hrs or less
Product Backlog

Product Owner and Team create a backlog of work

based on the product Vision and Roadmap
§  A collection of high level requirements, represented by User
Stories, that will deliver the vision and roadmap This Iteration

§  Owned by the Product Owner

Next Iteration
§  Prioritized by the Product Owner with input from the team

Time / Priority
§  Created collaboratively
Future Stories
in this Release
§  Elaborated “just in time” due to changes that may occur

* Backlog: list of work that needs to be done Future Releases

12
Exercise: Product Vision

Start with a verbal description, keep it simple and Component Type of Informa/on Sample
[Customer benefit] -> use this in the
include the Business Value. For
summary

..of priori/za/on, approval, and management
[Statement of business need] – the
§  Represent the future and write the vision as such. Who
problem
of soEware projects that include costs,
quality, and /me to value…
§  Anyone off the street should be able to
Requires a uniform standardized PorPolio &
understand the vision. It can range from a The
[Summary of XXX solu/on] – the answer
Program Management (PPM) Solu/on
(future state)
sentence or to a small paragraph with emphasis enabled by process and technology

on small. [Jus/fica/on of solu/on] – why this is

common discipline of Project Management in
Is a a consistent, repeatable way backed by
§  Vision statements differ from mission good
technology to increase project visibility
statements.
Increase overall ROI by showing visibility into:
§  While a vision statement is the “Where we
• Project Comple/on Status
want to be in xx time?” the mission
statement is the “How we are going to get That will
[Statement of benefit] – could be a • Resource U/liza/on Management
for shared resources across projects
business or IT benefit
there?” • Highest value projects that
§  Inputs into the Vision statement may include: maximizes customer benefits
Increase comple/on percentage of projects
§  Current chief pain points started each year by 50%
§  Business drivers [Summary of current state applicable to
Today, where it’s difficult to understand
Unlike capacity using empirical and quan/fiable
§  Client expectations of the future state the problem] – what they do now
metrics for resource alloca/on
…solu/on enables a common view into the
§  Understanding of how the Business/IT [XXX Solu/on roadmap to value] – state capacity of the organiza/on to take on work,
Our
Process should work (DevOps) what value this will bring see bo_lenecks, and iden/fy opportuni/es to
organize resources
§  Architectural drivers
13
Creating a Product Vision
Advanced Topics and
Supplement

14
Empirical Planning

DeterminisEc OYen what the

Planned consumer wants
Planning
Finish
Start

S1 Releases to produc.on
TargeEng what the
S5
Consumer needs!
S2
S3 S6
S4 S7
Empirical Actual
Planning Finish
(With
Feedback loops
at every stage)
15
Organizational Impact before Achieving Desired State (or TANSTaaFL*)

▶  This J-Curve aims to show

that for any desired
improvement in
capability there will be a
decline in capability
before there is an
improvement.
▶  Depth of the curve
will be dependent on
iden.fica.on and
engagement of
change agents (early
adopters) within the
organizaEon.
▶  Our goal will be to
reduce the “J” curve as
much as possible

16
Collaborative Lifecycle Management is designed to transform software delivery

“Collaborative lifecycle management (CLM) is the marriage of business

management to software engineering made possible by tools that facilitate
and integrate requirements management, architecture, coding, testing,
tracking, and release management.”
Choose Vertical Slices, Not Layers - Example
 Why We Choose Vertical Slices, Not Layers
Layers approach:
•  Developing in layers delays value delivery!
•  CompleEon of each layer is NOT a deliverable
–  Use of mocks and stubs to subsEtute for missing pieces
–  Missing pieces are usually owned by other teams
• Need End-to-End TesEng to prove successful integraEon
–  Mocks and stubs have been replaced with real calls and that the network is properly configured
–  DONE is NOT potenEally shippable/deliverable!

VerEcal Slices Approach:
•  Features deliver demonstrable behaviors
•  Self contained, demonstrable slices
•  User stories describe increments that can be finished in an IteraEon
•  It may take one-or-more iteraEons to deliver the whole feature
Features & Epics

An epic is a very large user story that is eventually broken down into smaller stories.
§  Example:
§  As a manager, I want to be able to get reporting on all policies in my segment, including
the premium, claim, and loss control details for each one.
§  Smaller stories:
§  As a manager, I want to get reporting on the number of policies sold by my segment so I
can evaluate the quote to sale ratio.
§  As a manager, I want to see a loss control report for the policies in my segment so that I
can evaluate potential losses for my segment

20
Roadmap and Release Plan

With a prioritized and sized backlog, we can develop a high level plan for delivering the work in
the Product Backlog. This will be a Road map.
§  What is the best order for the features to be delivered?
§  Will we be delivering the highest value items first?
§  Will we be addressing the highest risk items early?
§  How many Releases will it take to deliver the Product Backlog?
§  The next level of detail will be to further define the next Release.
§  How many sprints will be in the Release?
§  What is the estimated velocity for the team per Sprint?
§  Which user stories should we plan to deliver?
§  Road Map and Release Plans allow for conversations of trade offs and reprioritization

21
What is a User story?

A backlog consists of work in the form or User Stories

promise of a future conversation

CARD simple statement of what the customer needs
annotated as necessary

vehicle to a discussion between team and PO

CONVERSATION details refined, everyone’s questions answered
all agree to the meaning of the story

acceptance criteria
CONFIRMATION tests confirm the story was coded correctly
basis for test plan but not only input

A requested functionality, written in plain English from the end user perspective that is easy for everyone to
understand what is being requested and why

Represents a thin “slice of the application” through all layers providing value to the business when complete.

Remember the three Cs

22 * Ron Jeffries
Definition of DONE and Acceptance Criteria
Definition of DONE (DOD) Acceptance Criteria
A documented agreement by the team, Acceptance criteria are the requirements
product or program that indicates when that have to be met for a story to be
each story is done. assessed as complete.
Failure to meet these criteria at the end of Spell out what a Product Owner expects and
a sprint means the work should not be what a team needs to accomplish.
counted as done or toward that sprint's
velocity. What the Product Owner needs to see in

AND
order to accept the story as complete.
Fully tested and documented working
software are key components of the DOD. Can be a measurement for things like
performance.
Often includes deployment to a specific
Well thought out and written before
environment (QA – sprint boundary, UAT –
release boundary). development begins in order to capture
intent rather than development reality.
Displayed prominently in order to reduce
misunderstandings and conflict over Indicates WHAT is expected and not HOW it
will be implemented.
“done.”
Provides clarity on testing guardrails.
Often includes JIT documentation: System
Diagram, Support, FAQ, Web Help. Includes system documentation over project
23 documentation.
Agile Manifesto – The Values

We are uncovering better ways of developing Software by doing it and helping

others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

? Responding to change over

Following a plan

That is, while there is value in the items on the right, we value the items
on the LEFT MORE.

24
The 12 Principles of Agile
#1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s
#2 competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
#3 shorter timescale.
#4 Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them
#5 to get the job done.
The most efficient and effective method of conveying information to and within a development team is
#6 face-to-face conversation.
#7 Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to
#8 maintain a constant pace indefinitely.
#9 Continuous attention to technical excellence and good design enhances agility.
#10 Simplicity - the art of maximizing the amount of work not done - is essential.
#11 The best architects, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
#12 accordingly.
Source: hfp://agilemanifesto.org/principles.html
25
Changing to a Value-Driven Model

TRADITIONAL AGILE
FIXED / CONSTRAINT SCOPE COST SCHEDULE

VALUE / VISION
DRIVEN

PLAN
DRIVEN

VA R I A B L E COST SCHEDULE FEATURES

26
How do Teams work?
SCRUM – an
Team Progress
Agile Process
for Teams
Organized around the work – not
around Projects
Priority driven work
•  Based on Voice of the Customer
Focus on Deliveries in increments Incremental
7 – 9 multi-disciplined staff Deliveries
•  Usually highly loaded with
Developers
Co-Located whenever possible
Embedded Voice of the Customer
(Product Owner)
Simple, Self-Managed, Self-
Motivated to get the job done with:
•  Authority
•  Accountability
Prioritized Work List
•  Responsibility
Sprint Goals (Sprint Deliverables)
Prioritized Product
Wish List
27