Agile and lean product development the fundamentals

Delivering value early
and often, giving
ourselves the best
opportunity to beat the
competition to market,
realize revenue and
discover insights that
we can use to help us
improve

The Fundamentals

 What's in it for You
 The Business Proposition
 Mastering Agile and Lean Product (System-Software)
Development with Scrum
 User Stories Applied
 5 Levels Agile Planning
 Monitoring Progress and Business Value-Added

3

How to Organize a Children's Party


What Type of System is Ours?
Chaotic
Ordered
Complex


Four Spheres
of Influence
1. Stakeholder Needs and Business Processes
2. Architecture and Design
3. Technology CMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002

4. Program/Project Management

These four spheres are simultaneously defined and traded through the life of an agile and lean project because a
decision in one sphere will inform and likely constrain the decisions that can be made in another sphere

1. Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (including
quality attributes such as performance, security and reliability), end-user business processes, business
drivers and operational environment.
2. Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, the
relationships between them, and how they fit with the enterprise system. The elements include
structure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economic
and technologic constraints and tradeoffs.
3. Sphere 3 - Technology: This sphere denotes available and emerging technology and products, non-
development items and relevant standards.
4. Sphere 4 - Program/Project Management: This sphere denotes the management aspects of the
project. These aspects consider the cost, schedule and risk of building, fielding and supporting the
solution. Key to these management aspects are the cost, schedule and risk of changing the necessary
business processes. 7
Copyright © 2008 Russell Pannone. All rights reserved.

A Common Delivery Framework
Common Delivery Framework

Work Type
USAIT performs multiple types of work:
A common delivery framework
Standard Practices
(programs, projects, enhancements, of
introduces a consistent governance
break-fix, maintenance operations)
work prioritization, selection, Solution Approach

communication and representation of
These work progression to completion
that work‟s types are supported by
standard practices whichCommittee,
(i.e. Executive Steering establish
expectations of theCommittee,
Portfolio Steering minimum activities
that must be conducted Committee,
Infrastructure Steering to ensure a
viable solution is created (i.e.
Architecture Review Board,
requirements, funding, testing,
Enterprise Change Management
deployment)
At the core of the framework is the solution approach – where the actual work gets
done. The framework itself may establish guidelines to aide in choosing a solution
approach, but does not dictate any particular approach.

The team doing the work is empowered to make this choice!

8

Roadmap to “being” agile and lean
Objectives
 Delivery of commercial or operational value early and
often, giving ourselves the best opportunity to beat the
Agile competition to market, realize revenue and discover
Coaching & insights that we can use to help us improve
Training  Cross-functional, collaborative and adaptive teams
developing and delivering value-added product (system-
software) increments in a continuous flow from
requirements to deployment
 Avoiding the high cost of discovering defects late in the
Scrum
Cultural Agile development cycle by discovering defects early in the
Coaching &
Renewal Adoption Training
development cycle which is accomplished by eliminating
waste, increasing feedback loops and developing code
from the point of view of provability and outside-in design
 Emphasis is placed on the need for teams to nurture group
cohesion, and paying attention to norms that serve as a
guide that strengthens positive practices
Organizational
Change  Minimizing frustration levels and making the art and
Management science of system-software development enjoyable and
not a burden or death march
 The what, why, and how of agile/lean product (system-
software) development and delivery is not one persons
vision alone; to become reality it needs to be a "shared"
vision through negotiation and compromise between
individuals, the team and the organization


SS Agile SS Agile

11

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

Development – including hands-on exercise

14

Recent
Data Points

Russell Pannone (805) 910-6481 15

Gain
feedback Accept Lower
through change project risk
iterative without through
incremental slowing higher
value down visibility
delivery

Delivering
value early
and often,
giving
ourselves
the best
opportunity
to beat the
competition
to market,
realize
revenue
and
discover
insights
that we can
use to help
us improve

19

Copyright © 2005, Mountain Goat Software

1. Agile puts the Product Owner (aka “the business” or customer representative) in the
driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get
to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice
assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the
development process.

2. Agile allows the business to quickly react to changing market conditions and needs – The only
thing constant in today‟s economy is change. Businesses need to be able to make quick course corrections in order to
survive.

3. Agile provides visibility into the development process – For many customers software development is a
dark art. They don‟t have the background in order to understand the technical details and in most cases the development
team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development
lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible
for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system-
software product

20

Tooling Project - Product Backlog

21

1. Performing tasks to
complete the story
2. Completing the story
based on story
acceptance criteria
and team's definition
of done
3. Developing and
delivering commercial
or operational value
incrementally


Reduce Waste Feedback Loops
• Remove what isn’t of • Sprint Review & Planning
value to the customer • Sprint Retrospective
• Quicker delivery of value • Daily Scrum
& ROI
23

 Mastering Agile and Lean Product (System-
Software) Development

24

Candidate Practices

A practice is a common approach for doing something with a specific purpose in mind

Usage scenario
– When a project team wants to “be” agile they
self-organize & self-direct around the 9 practices
– The team then selects 1 or more practice to
apply to their work at hand
Benefits
– Iterative & Incremental adoption of “being”
agile and lean
– Gives team a context and narrow focus to rally
around
– Provides a non-threatening easy way for team
to learn together, “be” agile, apply an iterative
and incremental approach, and get better at
what we do
26

Copyright © 2008 Ivar Jacobson Consulting.

Sprint/Iteration

Traditional Development
 implied sequential “waterfall”
 time delay in obtaining feedback

Iterative & Incremental
Development and Delivery

What is Iterative and Incremental Development?
Iterative development is a time-boxed approach that
“cycles" through a set of activities, from
understanding requirements to producing and
refining an increment of the product

29

Scrum Explained
“The… „relay race‟ approach to
product development…may conflict
with the goals of maximum speed
and flexibility. Instead a holistic or
‘rugby’ approach—where a team
tries to go the distance as a unit,
passing the ball back and forth—
may better serve today’s
competitive requirements.”- Hirotaka
Takeuchi and Ikujiro Nonaka, “The New New Product Development
Game”, Harvard Business Review, January 1986

In Scrum you work in iterations
delivering value-adding results
incrementally


Scrum Roles & Definitions
(continued on next slide)

Copyright © 2005 Mountain Goat Software.


(continued on next slide)



(continued from previous slide)



Kanban Board
Pending WIP Done
Story Story
Story
Story Story
Story
Define Story
Story Story Story
Story
Story Story

Story
Story Story Story
Story Story
Story
Story Build & Story
Test Design
Implement
Story Story
Story Story

Story Story Story

Story
Story

Story
Story Story
Code
Story Story



40

User Stories Business Story Points
Priority
Story A 1 5
Story B 2 8
Story C 3 1
Story D 4 8
Story E 5 2
Story F 6 2
Story G 7 2
Story H 8 8
Story I 9 5
Story J 10 1

Copyright@ 2008 Russell Pannone. All rights reserved. 41

A story is a “placeholder”
for a requirement formulated as a
brief description written in the
everyday language of the customer
or user describing desired
functionality; containing just
enough information so that the
product team can produce a
reasonable estimate of the effort to
implement it

Five (5) “whys” analysis applied as an effective reflective
technique in the world of “being” agile and lean
1. Why is our Product Owner, unhappy?
Because we did not deliver the product release and business value when we
said we would
2. Why were we unable to meet the agreed upon timeline or schedule for delivery?
The product took much longer to develop than we thought it would
3. Why did it take so much longer?
Because we underestimated the complexity and uncertainty of the stories
4. Why did we underestimate the complexity and uncertainty?
Because we did not have acceptance criteria associate with each story, our
stories were not at the right level of detail and we did not realistically size
each story prior to committing to a schedule for delivering the release
5. Why didn't we do this?
Because the higher powers were still working under the traditional waterfall
planning mental-model, as a result we felt pressure to work faster and
skipped steps

 Solution: We clearly need to review and improve our approach to writing
stories, prioritizing stories, sizing stories, deriving/estimating duration and
committing to a schedule for delivering the product >>>>> Then get buy-in
and visible support from the higher powers

Where do
Optional
Stories
come from
Optional

Optional
Bus
Strategy

Use Cases
Business
Model

System Requirements
Customer Functional

Business Partner
&
Non-Functional
Product Owner
Team Solution/IT-Services


Characteristics of good stories
As a <who> I want <what> so that <why>
 A good story is negotiable, testable, estimatable, commercially or
operationally value-adding, cohesive and loosely-coupled
 It is not an explicit contract for features or functionality; rather stories
are short descriptions of functionality, the details of which are to be
refined in a conversation between the Product Owner (aka, the business or
customer) and the development team
 The challenge comes in learning to include just enough detail to be able to
prioritize and estimate the size of story and minimize ambiguity
Story1 Story4
As an eligible user, I want to pay the As an eligible user, I want to access my Story11
onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list
that I can access my driver’s record in information to keep it current of assembled answers to questions
the future asked most frequently of the DMV

Story5
Story2 Story12
As an eligible user, I want to access my
As an eligible user, I want to create a As an eligible user, I want to be able
record and change any or all of my
unique user name and password so find an address for my local DMV
information to keep it current
that my access is limited to my record office and print the results
and to track activity and payment
Story6 Story13
Story3 As an eligible user, I want multiple As the application, I want to maintain
As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each
record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits
correct DMV site that require payment

Meeting the Product Owner’s Conditions-of-Satisfaction

 Outside-In-Design > One of the key characteristics that
make stories so fitting for delivering value early and often is that
they focus on describing the source of value to the Product
Owner, instead of the mechanics of how that value is delivered
 Stories strive to convey the Product Owner wants and needs, the
who, what and why and not the specifics of the solution or the
details about “how” the team will implement the story


Story Size
 The fact of the matter is some stories can be too big,
some can be too small, and some can be just right
 Stories that are too big are called Epics
 Epics are difficult to work with because they frequently
contain multiple stories
 Epics typically fall into one of two categories:
 The compound story
 The complex story Story
record, so that I can verify that it is

Epic (compound story)
correct

As an eligible user, I
Story

want to view , add,
record and delete any or all of my
information, so that I can keep it

change or delete my
current

DMV information so that Story

I can keep it current record and change any or all of my
information, so that I can keep it
current

Complex Story
 Unlike the compound story, the complex story is a story that is inherently
large and cannot easily be disaggregated into a set of constituent stories
 If a story is complex because of uncertainty associated with it, you should
estimate the size of the story at the highest range of your estimating scale
(1, 2, 3, 5, 8, 13, 21, 34)
 Then prior to the sprint where you are going to pull it in have an
investigate story to more clearly understand what the solution involves to
deliver this story
Epic (complex story)
As an eligible user, I want multiple payment options to pay my fees so that
I am able to access the features of the DMV site that require payment
For example, suppose the team is given the story depicted above, but none of the
developers has ever done credit card processing before. The team would then decide
to disaggregate the story like this:
• Investigate credit card processing over the web
• A user can pay with a credit card
In this case the first story will send one or more developers on a spike. When complex
stories are split in this way, always define a time-box around the investigative story, or
spike.

Acceptance
Criteria

 Acceptance criteria, represents the details for a story and specifies the
desired behavior and functionality the system-software must implement
 Acceptance criteria answer the question, “How will I know when I’m done
with the story?”
 Acceptance criterion is high level tests to verify and validate the
completeness of a story or stories implemented during a Sprint/Iteration,
expressed in a business domain language
 These tests are created ideally through collaboration between business
customers, business analysts, testers and developers; however the Product
Owner (aka, the business or customer) is the primary owner of these
conditions-of-satisfaction
 Test cases and acceptance criteria are two different things
 Test cases answer the questions, “How do I test and what are the test
steps?”

 Depiction of the
user interface or
maybe even a
report layout, is
just as much a part
of the details
behind a story as
acceptance criteria
 Wireframes and
screen mockups are
often attached to
stories as a basic
visual guide used in
interface design by
the development
team
 Low fidelity
diagrams depicting
a candidate solution
may also be
attached to stories
to visually
communicate its
design 51

Product Backlog
high

priority
low

Five factors to consider when prioritizing
1.The commercial or operational value of the delivered story
2.Degree of uncertainty - the amount and significance of learning and new
knowledge gained by developing the story; focused on requirements
and technology
3.The amount of risk removed by developing and delivering the story –
focused on schedule, budget, scope, operation, technology
4.Dependencies – stories that must be developed together and are
delivered together to provide value to the customer
5.The cost of developing and delivering the story
52

Story Prioritizing Exercise

53

Story Points: Relative Measure
of the Size of a Story
Sizing stories is often confused with "how
long" it takes to implement it but in fact "how
big" and "how long" are very different things

 The "how long" is highly dependent on
which developer is performing the work
 The "how big" bears no relationship to
who is performing the work


56

Why are We
Doing This

1. Refine team‟s understanding of
requirements (stories)
2. Estimate level-of-effort
3. Derive high-level cost, schedule,
and scope
57

Look, See, Imagine, Act

Remove Ambiguity

Agile & Lean Product Development
and a
Project Delivery Framework

ROM estimate of
Cost, Schedule, Scope Commit to Cost,
Schedule, Scope


Velocity is a
measure of Deriving estimates
a team‟s  4 iterations based
rate of on team velocity
progress per  Each iteration 3
weeks long
Iteration
 12 weeks total
duration
 Estimated cost of
$15,000 per
iteration
 Estimated total
cost of $60,000


1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the level-of-
effort required to
complete the task


Team Velocity


If my velocity, as a painter is 30–40 points every 2 days,
and
I have 10 homes to paint, like this, I have a total of 490 points
(49 points X 10 houses = 490 total points)
----------------------------------------------------------------------
I can then take the mean of my velocity which is 36
and
figure out how many sprints/iterations I would have
490 / 36 = 13.6111
----------------------------------------------------------------------
Since my sprints/iterations are 2 days long it will take me
27 – 28 calendar days to complete this job
2 (days per sprint) X 13.6111 (number of sprints) = 27.2
69

Technique for Deriving Story Points

Planning Poker

Story Sizing Exercise

71

 5 Level Agile Planning

72

5 levels of Agile Planning
What, Who, Why, When, Constraints,
Product Vision Assumptions
Releases – Date, Theme/Feature Set,
Product Roadmap Objective, Development Approach

Iteration, Team Capacity, Stories, Priority,
Release Planning Size, Estimates, Definition of Done

Stories – Tasks, Definition of Done
Iteration Planning Level-of Effort, Commitment

1. What did I do yesterday?
Daily Planning 2. What will I do today?
3. What is blocking me?

Integrating Agile and Lean
System-Software Development with a

Common Delivery Framework
USAIT performs multiple types of work:
(programs, projects, enhancements, of
introduces a consistent governance Work Type

break-fix, maintenance operations)
work prioritization, selection, Standard Practices

These work types are supported by of
communication and representation
standard practices whichto completion
that work‟s progression establish Solution Approach

(i.e. ESC, PSC, ISC, ARB, ECM,
expectations of the minimum activities
phases)
that must be conducted to ensure a
viable solution is created (i.e.
requirements, funding, testing,
deployment)

At the core of the framework is the solution approach – where the actual work gets
done. The framework itself may establish guidelines to aide in choosing a solution
approach, but does not dictate any particular approach.

The team doing the work is empowered to make this choice!

76
Delivery Framework

Agile & Lean Product Development
and a

ROM estimate of
Cost, Schedule, Scope Commit to Cost,
Schedule, Scope


Product Vision What, Who, Why, When, Constraints, Assumptions



Product Vision
 What
 Who (Stakeholders)
 Why
 When
 Constraints &
Assumptions “If you don't know where you are
going, that's where you'll end up.”
-Yogi Berra
79

Product Vision
 What
 Summary of the major benefits and features the product will provide
 Gives context to the reader
 Defines the business context for the product. In which domain is it going to
function (for example, telecom or bank) and what market—who are the users?
State whether the product is being developed to fulfill a contract or if it is a
commercial product.

 Who (Stakeholders)
 There are a number of stakeholders with an interest in the development and not
all of them are end users. Think of this as outside-in-design.
 Customer/Consumer
 Other vested interests
 Provides the background and justification for why the requirements are needed

Continued on Next Page
80

Continued from Previous Page
Why
Need and opportunity

When
 Begins the process of project scheduling by illuminating the stakeholders’ time expectations
regarding the product. Also helps you dig into their expectations by defining the circumstances in
which the new product would be used.
Constraints & Assumptions
 Express the constraints under which the project is undertaken. These constraints impact risk and
cost. They could be things like external interfaces that the product must adhere to, standards,
certifications or a technical approach employed for strategic reasons, such as using a certain
database technology or distribution mechanisms.

Releases – Date, Theme/Feature Set, Objective,
Product Roadmap Development Approach



If you don't know where you are going, it's impossible to determine the
best way to get there.

A product roadmap is an essential tool for product planning and
development.

Product roadmaps outline when products are scheduled for release and
include an overview of their primary and secondary features.
83

Tooling Life Cycle
Reporting
Life Cycle

Planning/ Receiving/ Inventory Tool End of
Procurement
Sourcing Warehousing Management Utilization Life

Tool received OEM or tooling
Need for a TB submits SC will bin
at PIT Tool utilized deems tool
tool & quantity PR through or check out
USA dock On aircraft unserviceable
defined Sceptre For use

SC receives and Tool shipped
bins the tool Kit back to USA
Process Steps

TS sources TP generates PO Tool then
& gets quote/ that transmits management checked in/out, PIT
delivery date to OEM Tool Sup checks calibrated, shipped,
for damage & Reported on
calibration Tool repeatedly Tool Sup marks
Repair tool BER, lost
OEM confirms or other
price & LT Tool Sup gives
stores
next steps
Theme Tool changed
OEM makes Stores stocks To inactive
tool part or ships to
another location Note: some of these
= System Transaction Process steps may Tool held
TS = Technical Sourcer vary at non-maintenance In case of
TP = Technical Purchaser Tool arrives Future need
Tool Sup = Tooling Supervisor at new station stations For it
TB = Tooling BA
LT = Lead Time
USA = US Airways Tool received
SC = Stock Clerk in Sceptre 84
BER = Beyond Economical Repair

Copyright © 2005, Mountain Goat Software

1. Agile puts the Product Owner (aka “the business” or customer representative) in the
driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get
to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice
assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the
development process.

2. Agile allows the business to quickly react to changing market conditions and needs – The only
thing constant in today‟s economy is change. Businesses need to be able to make quick course corrections in order to
survive.

3. Agile provides visibility into the development process – For many customers software development is a
dark art. They don‟t have the background in order to understand the technical details and in most cases the development
team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development
lifecycle, providing enhanced visibility.

4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible
for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system-
software product

86

Tooling Project - Product Backlog

87

Characteristics of good stories
As a <who/user> I want <what/goal> so that <why/reason>

 A good story is negotiable, testable, estimatable, commercially or
operationally value-adding, cohesive and loosely-coupled
 It is not an explicit contract for features or functionality; rather stories
are short descriptions of functionality, the details of which are to be
refined in a conversation between the Product Owner (aka, the business or
customer) and the development team
 The challenge comes in learning to include just enough detail to be able to
prioritize and estimate the size of story and minimize ambiguity
Story1 Story4
As an eligible user, I want to pay the As an eligible user, I want to access my Story11
onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list
that I can access my driver’s record in information to keep it current of assembled answers to questions
the future asked most frequently of the DMV

Story5
Story2 Story12
As an eligible user, I want to create a As an eligible user, I want to be able
record and change any or all of my
unique user name and password so find an address for my local DMV
information to keep it current
that my access is limited to my record office and print the results
and to track activity and payment
Story6 Story13
Story3 As an eligible user, I want multiple As the application, I want to maintain
As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each
record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits
correct DMV site that require payment

Acceptance
Criteria

 Acceptance criteria, represents the details for a story and specifies the
desired behavior and functionality the system-software must implement
 Acceptance criteria answer the question, “How will I know when I’m done
with the story?”
 Acceptance criterion is high level tests to verify and validate the
completeness of a story or stories implemented during a Sprint/Iteration,
expressed in a business domain language
 These tests are created ideally through collaboration between business
customers, business analysts, testers and developers; however the Product
Owner (aka, the business or customer) is the primary owner of these
conditions-of-satisfaction
 Test cases and acceptance criteria are two different things
 Test cases answer the questions, “How do I test and what are the test
steps?”

 Depiction of the user
interface or maybe even a
report layout, is just as
much a part of the details
behind a story as
acceptance criteria
 Wireframes and screen
mockups are often
attached to stories as a
basic visual guide used in
interface design by the
development team
 Low fidelity diagrams
depicting a candidate
solution may also be
attached to stories to
visually communicate its
design Copyright © 2008 Russell Pannone. All rights reserved. 90

Iteration, Team Capacity, Stories, Priority, Size,
Release Planning Estimates, Definition of Done



Product Vision

Product Roadmap

Iteration Plan

Product Backlog

Review and Adapt Develop

Release Plan

Copyright © 2008 Russell Pannone. All rights reserved. Adapted from “Agile Project Management” Jim Highsmith Copyright 2004 92

The Release Plan
The Release Plan is determined from
the team’s velocity; initially this is an
estimate, a best guess until the team’s
actual velocity can be determined from
historical data
We create the Release plan from
 The size estimate
 The velocity (“size per iteration”)
The Release plan shows what will be
worked on in each iteration
 Each iteration contains approximately the same number of
story points and is time boxed by iteration length


Components of the Release Plan

The Release Plan is comprised of:
1. The release theme
2. The release content
3. Business value statement for the release
4. The release timeline


Creating the Release Plan
(continue from previous slide)

Once we have identified the theme and content for each
release, we can prepare a brief summary of the Business Value
to be delivered at each release

Example:
Release 1- This release implements ……. and allows users to
………………..


Release Timeline

 Stories at the right level of detail
 Prioritized stories
 Sized stories

 Deriving/estimating duration and
cost to deliver product

Velocity is a
measure of a Deriving estimates
team’s rate of  4 iterations based
progress per on team velocity
Iteration  Each iteration 3
weeks long
 12 weeks total
duration
 Estimated cost of
$15,000 per
iteration
 Estimated total
cost of $60,000



Stories – Tasks, Definition of Done Level-of Effort,
Iteration Planning Commitment


1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the level-of-
effort required to
complete the task


Working software & demo
Unit test
Code review
Installer
Tests
Functional
Performance
Regression
Documentation
User docs/Online help
Internal design docs
Release notes
API documents
Copyright@2009 SolutionsIQ All rights Reserved

102

1. Performing tasks to
complete the story
2. Completing the story
based on story
acceptance criteria
and team's definition
of done
3. Developing and
delivering commercial
or operational value
incrementally


& ROI
106


107

Looking at SCRUM
from a Different Perspective

- Planning
- Product Owner - Daily Standup
- Scrum Master - Sprint Review
- Team - Retrospective

Progress
Items


Velocity Chart Example
45

40

35

30

25
Velocity

20

15

10

5

0
1 2 3 4 5 6 7 8 9 10

Sprint 110

Burndown Chart consists of
Story Points

| | | | | | | | | | |
S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11

On a Scrum project, the team tracks its progress against a release plan by
updating a release burndown chart at the end of each Sprint.

The horizontal axis of the release burndown chart shows the Sprints; the
vertical axis shows the amount of work remaining at the start of each Sprint in
Story points.

Burnup Chart Example

112

Gain
feedback Accept Lower
through change project risk
iterative without through
incremental slowing higher
value down visibility
delivery

Delivering
value early
and often,
giving
ourselves
the best
opportunity
to beat the
competition
to market,
realize
revenue
and
discover
insights
that we can
use to help
us improve

113

& ROI
114

Roadmap to “being” agile
• Delivery of commercial or operational value early and
often, giving ourselves the best opportunity to beat
the competition to market, realize revenue and
discover insights that we can use to help us improve
Agile
• Cross-functional, collaborative and adaptive teams
Coaching & developing and delivering value-added product
Training
(system-software) increments in a continuous flow
from requirements to deployment
• Avoiding the high cost of discovering defects late in the
development cycle by discovering defects early in the
Agile development cycle which is accomplished by
Scrum
Cultural Adoption Coaching & eliminating waste, increasing feedback loops and
Renewal Training developing code from the point of view of provability
and outside-in design
• Emphasis is placed on the need for teams to nurture
group cohesion, and paying attention to norms that
serve as a guide that strengthens positive practices
Organizational
Change • Minimizing frustration levels and making the art and
Management science of system-software development enjoyable
and not a burden or death march
• The what, why, and how of agile/lean product
(system-software) development and delivery is not
one persons vision alone; to become reality it needs to
be a "shared" vision through negotiation and
compromise between individuals, the team and the
organization 115

Agile workflow in DPaCE phases
DPaCE Project Delivery Framework

End
End
Discover (justify)
Discover (justify) Plan (commit)
Plan (commit) Control (actualize)
Control (actualize) (assess)
(assess)

BTR TRR CARE KPIs

Test Scripts & Results

Enterprise
Change
Production
Notification
Signature
Document

Release

Initial
Product Sprint
Backlog
Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 ... 10

Groom Product Backlog

Mapping Agile to DPacE

Agile and lean product development the fundamentals

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Agile and lean product development the fundamentals

Ähnlich wie Agile and lean product development the fundamentals (20)

Mehr von Russell Pannone

Mehr von Russell Pannone (13)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile and lean product development the fundamentals