Agile and lean product development the fundamentals
-
Upload
russell-pannone -
Category
Technology
-
view
2.230 -
download
0
Transcript of 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
2Copyright © 2008 Russell Pannone. All rights reserved.
3
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
4
Class Exercise
How to Organize a Children's Party
Copyright © 2008 Russell Pannone. All rights reserved. 5
What Type of System is Ours?
Chaotic
Ordered
Complex
Copyright © 2008 Russell Pannone. All rights reserved. 6
Four Spheresof Influence
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.
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
7
CMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002
Copyright © 2008 Russell Pannone. All rights reserved.
1. Stakeholder Needs and Business Processes
2. Architecture and Design
3. Technology
4. Program/Project Management
8
A Common Delivery FrameworkCommon Delivery Framework
Work Type
Standard Practices
Solution Approach
A common delivery framework
introduces a consistent governance of
work prioritization, selection,
communication and representation of
that work‟s progression to completion
(i.e. Executive Steering Committee,
Portfolio Steering Committee,
Infrastructure Steering Committee,
Architecture Review Board,
Enterprise Change Management
USAIT performs multiple types of work:
(programs, projects, enhancements,
break-fix, maintenance operations)
These work types are supported by
standard practices which establish
expectations of the minimum activities
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!
Objectives
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
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 development cycle by discovering defects early in the 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
Minimizing frustration levels and making the art and 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
9
Roadmap to “being” agile and lean
Copyright © 2008 Russell Pannone. All rights reserved.
Agile Adoption
Agile Coaching & Training
Scrum Coaching & Training
Organizational Change
Management
Cultural Renewal
10Copyright © 2008 Russell Pannone. All rights reserved.
11
SS Agile SS Agile
Copyright © 2008 Russell Pannone. All rights reserved.
12
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 competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
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 to get the job done.
Working software is the primary measure of progress.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, 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 accordingly.
14
What's in it for You
The Business Proposition
Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise
User Stories Applied
5 Levels Agile Planning
Monitoring Progress and Business Value-Added
15
Recent
Data Points
Russell Pannone (805) 910-6481
16
17
Copyright@ 2008 Russell Pannone. All rights reserved.
19
Gainfeedbackthroughiterative
incrementalvalue
delivery
Acceptchangewithoutslowingdown
Lowerproject risk
throughhigher
visibility
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
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
Copyright © 2005, Mountain Goat Software
Copyright © 2008 Russell Pannone. All rights reserved.
Copyright © 2008 Russell Pannone. All rights reserved.
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
22
Reduce Waste
• Remove what isn’t of value to the customer
• Quicker delivery of value & ROI
Feedback Loops
• Sprint Review & Planning
• Sprint Retrospective
• Daily Scrum
23
24
What's in it for You
The Business Proposition
Mastering Agile and Lean Product (System-Software) Development
User Stories Applied
5 Levels Agile Planning
Monitoring Progress and Business Value-Added
Candidate Practices
A practice is a common approach for doing something with a specific purpose in mind
26
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
27Copyright © 2008 Russell Pannone. All rights reserved.
Copyright © 2008 Ivar Jacobson Consulting.
Sprint/Iteration
Traditional Development implied sequential “waterfall” time delay in obtaining feedback
Iterative & Incremental
Development and Delivery
29
What is Iterative and Incremental Development?
Copyright © 2008 Russell Pannone. All rights reserved.
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
30
31
Scrum Explained
Copyright © 2008 Russell Pannone. All rights reserved.
In Scrum you work in iterations
delivering value-adding results
incrementally
“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
32
Scrum Roles & Definitions(continued on next slide)
Copyright © 2008 Russell Pannone. All rights reserved.
Copyright © 2005 Mountain Goat Software.
33
Scrum Roles & Definitions(continued on next slide)
Copyright © 2008 Russell Pannone. All rights reserved.
Copyright © 2005 Mountain Goat Software.
34Copyright © 2008 Russell Pannone. All rights reserved.
Scrum Roles & Definitions(continued from previous slide)
Copyright © 2005 Mountain Goat Software.
35
Copyright © 2008 Ivar Jacobson Consulting.
Copyright © 2008 Ivar Jacobson Consulting.
Copyright © 2008 Ivar Jacobson Consulting.
Copyright © 2008 Russell Pannone. All rights reserved.
36Copyright © 2008 Russell Pannone. All rights reserved.
37
Class Exercise
38Copyright © 2008 Russell Pannone. All rights reserved.
Kanban Board
Pending WIP Done
Test
Define
Design
Code
Build & Implement
Copyright © 2008 Russell Pannone. All rights reserved.
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
Story
40
What's in it for You
The Business Proposition
Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise
User Stories Applied
5 Levels Agile Planning
Monitoring Progress and Business Value-Added
User Stories Business
Priority
Story Points
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
41Copyright@ 2008 Russell Pannone. All rights reserved.
42Copyright@ 2008 Russell Pannone. All rights reserved.
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
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
Five (5) “whys” analysis applied as an effective reflective technique in the world of “being” agile and lean
Copyright © 2008 Russell Pannone. All rights reserved. 43
44Copyright@ 2008 Russell Pannone. All rights reserved.
BusStrategy
BusinessModel
System RequirementsFunctional
&Non-Functional
Solution/IT-Services
Where do Stories
come from
Use Cases
45Copyright © 2008 Russell Pannone. All rights reserved.
Optional
Optional
Optional
CustomerBusiness PartnerProduct Owner
Team
Characteristics of good stories
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
46
Story1As an eligible user, I want to pay the onetime registration fee of $10, so that I can access my driver’s record in the future
Story2As an eligible user, I want to create a unique user name and password so that my access is limited to my record and to track activity and payment
Story3As an eligible user, I want to access my record, so that I can verify that it is correct
Story4As an eligible user, I want to access my record and delete any or all of my information to keep it current
Story5As an eligible user, I want to access my record and change any or all of my information to keep it current
Story6As an eligible user, I want multiple payment options to pay fees so that I am able to access the features of the DMV site that require payment
Story13As the application, I want to maintain an audit trail of changes for each eligible user record indicating all edits
Story12As an eligible user, I want to be able find an address for my local DMV office and print the results
Story11As an eligible user, I want to view a list of assembled answers to questions asked most frequently of the DMV
Copyright © 2008 Russell Pannone. All rights reserved.
As a <who> I want <what> so that <why>
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
47Copyright © 2008 Russell Pannone. All rights reserved.
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
Epic (compound story)
As an eligible user, I want to view , add, change or delete my DMV information so that I can keep it current
48
StoryAs an eligible user, I want to access my record, so that I can verify that it is correct
StoryAs an eligible user, I want to access my record and delete any or all of my information, so that I can keep it current
StoryAs an eligible user, I want to access my record and change any or all of my information, so that I can keep it current
Copyright © 2008 Russell Pannone. All rights reserved.
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.
49Copyright © 2008 Russell Pannone. All rights reserved.
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?”
50Copyright © 2008 Russell Pannone. All rights reserved.
51
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.
Copyright © 2008 Russell Pannone. All rights reserved.
Five factors to consider when prioritizing1.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
prio
rity
high
low
Product Backlog
Story Prioritizing Exercise
53
Copyright © 2008 Russell Pannone. All rights reserved. 54
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
55Copyright © 2008 Russell Pannone. All rights reserved.
56
Copyright © 2008 Russell Pannone. All rights reserved.
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
Copyright © 2008 Russell Pannone. All rights reserved.
Remove Ambiguity
Copyright © 2008 Russell Pannone. All rights reserved.
60
Agile & Lean Product Developmentand a
Project Delivery Framework
Copyright © 2008 Russell Pannone. All rights reserved.
ROM estimate of Cost, Schedule, Scope Commit to Cost,
Schedule, Scope
Copyright © 2008 Russell Pannone. All rights reserved. 61
Deriving estimates
4 iterations based on team velocity
Each iteration 3 weeks long
12 weeks total duration
Estimated cost of $15,000 per iteration
Estimated total cost of $60,000
Velocity is a
measure of
a team‟s
rate of
progress per
Iteration
Copyright © 2008 Russell Pannone. All rights reserved.
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
62
Copyright © 2008 Russell Pannone. All rights reserved. 63
Copyright © 2008 Russell Pannone. All rights reserved. 64
Copyright © 2008 Russell Pannone. All rights reserved. 65
Copyright © 2008 Russell Pannone. All rights reserved. 66
Copyright © 2008 Russell Pannone. All rights reserved. 67
Team Velocity
Copyright © 2008 Russell Pannone. All rights reserved. 68
69
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
Technique for Deriving Story Points
Planning Poker
71
Story Sizing Exercise
72
What's in it for You
The Business Proposition
Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise
User Stories Applied
5 Level Agile Planning
Monitoring Progress and Business Value-Added
Candidate Practices
A practice is a common approach for doing something with a specific purpose in mind
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
5 levels of Agile Planning
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
Integrating Agile and LeanSystem-Software Development with a
Project Delivery Framework
76Delivery Framework
A common delivery frameworkCommon Delivery Framework
Work Type
Standard Practices
Solution Approach
A common delivery framework
introduces a consistent governance of
work prioritization, selection,
communication and representation of
that work‟s progression to completion
(i.e. ESC, PSC, ISC, ARB, ECM,
phases)
USAIT performs multiple types of work:
(programs, projects, enhancements,
break-fix, maintenance operations)
These work types are supported by
standard practices which establish
expectations of the minimum activities
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!
77
Agile & Lean Product Developmentand a
Project Delivery Framework
Copyright © 2008 Russell Pannone. All rights reserved.
ROM estimate of Cost, Schedule, Scope Commit to Cost,
Schedule, Scope
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
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 Berra79
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
80
Continued on Next Page
WhyNeed 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.
Continued from Previous Page
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
83
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.
84
Tooling Life Cycle
Planning/
SourcingProcurement
Receiving/
Warehousing
Inventory
Management
Tool
Utilization
End of
Life
Need for a
tool & quantity
defined
TS sources
& gets quote/
delivery date
TB submits
PR through
Sceptre
TP generates PO
that transmits
to OEM
OEM confirms
price & LT
OEM makes
tool
Tool Sup checks
for damage &
calibration
Tool received
at PIT
USA dock
Tool Sup gives
stores
next steps
Stores stocks
part or ships to
another location
Tool received
in Sceptre
Tool arrives
at new station
SC will bin
or check out
For use
Tool then
checked in/out,
calibrated, shipped,
Reported on
repeatedly
Tool utilized
On aircraft
OEM or tooling
deems tool
unserviceable
Tool shipped
back to USA
PIT
Tool Sup marks
tool BER, lost
or other
Tool changed
To inactive
Tool held
In case of
Future need
For it
TS = Technical Sourcer
TP = Technical Purchaser
Tool Sup = Tooling Supervisor
TB = Tooling BA
LT = Lead Time
USA = US Airways
SC = Stock Clerk
BER = Beyond Economical Repair
= System Transaction
Kit
management
Reporting
Note: some of these
Process steps may
vary at non-maintenance
stations
SC receives and
bins the tool
Tool
Repair
Pro
ce
ss
Ste
ps
Lif
e C
yc
le
Theme
The Product Backlog is Derived from theProduct Vision and Roadmap
© Scott Ambler, 2004
85
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
Copyright © 2005, Mountain Goat Software
Copyright © 2008 Russell Pannone. All rights reserved.
Characteristics of good stories
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
88
Story1As an eligible user, I want to pay the onetime registration fee of $10, so that I can access my driver’s record in the future
Story2As an eligible user, I want to create a unique user name and password so that my access is limited to my record and to track activity and payment
Story3As an eligible user, I want to access my record, so that I can verify that it is correct
Story4As an eligible user, I want to access my record and delete any or all of my information to keep it current
Story5As an eligible user, I want to access my record and change any or all of my information to keep it current
Story6As an eligible user, I want multiple payment options to pay fees so that I am able to access the features of the DMV site that require payment
Story13As the application, I want to maintain an audit trail of changes for each eligible user record indicating all edits
Story12As an eligible user, I want to be able find an address for my local DMV office and print the results
Story11As an eligible user, I want to view a list of assembled answers to questions asked most frequently of the DMV
Copyright © 2008 Russell Pannone. All rights reserved.
As a <who/user> I want <what/goal> so that <why/reason>
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?”
89Copyright © 2008 Russell Pannone. All rights reserved.
90
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.
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
Product Vision
Release Plan
Iteration Plan
DevelopReview and Adapt
Product Backlog
Adapted from “Agile Project Management” Jim Highsmith Copyright 2004Copyright © 2008 Russell Pannone. All rights reserved. 92
Product Roadmap
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
Copyright © 2008 Russell Pannone. All rights reserved. 93
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
Copyright © 2008 Russell Pannone. All rights reserved. 94
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 ………………..
Copyright © 2008 Russell Pannone. All rights reserved. 96
Creating the Release Plan(continue from previous slide)
Release Timeline
Stories at the right level of detail
Prioritized stories
Sized stories
Deriving/estimating duration and cost to deliver product
Copyright © 2008 Russell Pannone. All rights reserved. 97
Copyright © 2008 Russell Pannone. All rights reserved. 98
Deriving estimates
4 iterations based on team velocity
Each iteration 3 weeks long
12 weeks total duration
Estimated cost of $15,000 per iteration
Estimated total cost of $60,000
Velocity is a measure of a team’s rate of progress per
Iteration
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
Copyright © 2008 Russell Pannone. All rights reserved.
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
100
101Copyright © 2008 Russell Pannone. All rights reserved.
102
Copyright@2009 SolutionsIQ All rights Reserved
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@ 2008 Russell Pannone. All rights reserved.
Product Vision
Product Roadmap
Release Planning
Iteration Planning
Daily Planning
What, Who, Why, When, Constraints, Assumptions
Releases – Date, Theme/Feature Set, Objective, Development Approach
Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done
Stories – Tasks, Definition of Done Level-of Effort, Commitment
1. What did I do yesterday?2. What will I do today?3. What is blocking me?
Copyright © 2008 Russell Pannone. All rights reserved.
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
104
Reduce Waste
• Remove what isn’t of value to the customer
• Quicker delivery of value & ROI
Feedback Loops
• Sprint Review & Planning
• Sprint Retrospective
• Daily Scrum
106
107
What's in it for You
The Business Proposition
Mastering Agile and Lean Product (System-Software) Development – including hands-on exercise
User Stories Applied
5 Levels Agile Planning
Monitoring Progress and Business Value-Added
108
Looking at SCRUMfrom a Different Perspective
Progress
Items
Copyright © 2008 Russell Pannone. All rights reserved.
Copyright © 2008 Russell Pannone. All rights reserved.
- Product Owner
- Scrum Master
- Team
- Planning
- Daily Standup
- Sprint Review
- Retrospective
Copyright@ 2008 Russell Pannone. All rights reserved. 109
110
Velocity Chart Example
0
5
10
15
20
25
30
35
40
45
1 2 3 4 5 6 7 8 9 10
Velo
cit
y
Sprint
Copyright@ 2008 Russell Pannone. All rights reserved.
Burndown Chart consists of
Copyright@ 2008 Russell Pannone. All rights reserved.
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.111
Sto
ry P
oin
ts
|
S2
|
S1
|
S4
|
S3
|
S5
|
S11|
S8
|
S9
|
S10
|
S7
|
S6
112
Burnup Chart Example
Copyright@ 2008 Russell Pannone. All rights reserved.
113
Gainfeedbackthroughiterative
incrementalvalue
delivery
Acceptchangewithoutslowingdown
Lowerproject risk
throughhigher
visibility
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
Reduce Waste
• Remove what isn’t of value to the customer
• Quicker delivery of value & ROI
Feedback Loops
• Sprint Review & Planning
• Sprint Retrospective
• Daily Scrum
114
• 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
• Cross-functional, collaborative and adaptive teams developing and delivering value-added product (system-software) increments in a continuous flowfrom requirements to deployment
• Avoiding the high cost of discovering defects late in the development cycle by discovering defects early in the 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
• Minimizing frustration levels and making the art and 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
Roadmap to “being” agile
Copyright © 2008 Russell Pannone. All rights reserved.
Agile Adoption
Agile Coaching & Training
Scrum Coaching & Training
Organizational Change
Management
Cultural Renewal
Mapping Agile to DPacE
Agile workflow in DPaCE phases
DPaCE Project Delivery Framework
End
(assess)
End
(assess)Control (actualize)Control (actualize)Plan (commit)Plan (commit)Discover (justify)Discover (justify)
BTR TRR CARE KPIs
Initial
Product
BacklogSprint 0 Sprint 4
Release
. . . Sprint
10
Groom Product Backlog
Sprint 1 Sprint 2 Sprint 3
Test Scripts & Results
Enterprise
Change
NotificationProduction
Signature
Document