Post on 17-May-2018
Delusions of Success: How Optimism Undermines Executives' Decisions (Source: Richard Hartley, HBR)
• Problem:
Humans seem hardwired to be optimists
• Optimism from cognitive biases & organizational pressures• Exaggerate talents & degree of control
• Attribute negative consequences to external factors
• Anchoring (relying too heavily on one piece of information) magnifies optimism• Most pronounced for new initiativesBest practice: Temper with “outside view”
Supplement traditional forecasting w/ statistical parametrics
AGILE IS EVEN MORE VULNERABLE TO OPTIMISM
Agile Projects Have A New Set of Risks• Using User Stories as size doesn’t mean they won’t
grow / change
• Requirements volatility can be even more drastic (design on the fly)
• Risk of lack of integration / regression testing from sprint to sprint
• Requirements growth due to regular wish lists
• Poorly constructed user stories may require modifications
• More
© 2013 Copyright Galorath Incorporated 3
But Did You Know SEER Supports Agile Development Estimation
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Generate Estimates for Each Phase of Development
Formal Estimation Process Is Appropriate for Agile Projects• Build Estimate With Best Available Information
• Expect Estimates At Feasibility And Concept Phases To Be Created the Same As Previously Built• Recommend:
• Use Previous Models Calibrated to Actuals
• Estimate Size by Analogy or Comparison
• Use a Knowledge Base Driven Estimation Tool
• Use Historical Databases For Estimate Reviews
• Okay To Assume An Agile Development• But Remember What You Don’t Know:
• Maturity Of The Team, Availability Of SMEs, Certified Scrum Master Available, Etc, Etc.
The Iron Triangle of a Project
• During a project a specified set of features need to be achieved during some specific time – by the given resources
• At least one of these three elements: Scope, Time, and Resources must vary, otherwise the quality of the work suffers!
© 2012 Copyright Galorath Incorporated 7
QualityResources Duration
Scope (features)
Estimating An Agile Project
QualityResources Duration
Scope (features)
• The Agile Manifesto was a defense of the “Iron Triangle”
• The “outer envelope” of a project still requires an estimate
• The size of a project’s Iron Triangle is estimatedby trading of Resources, Scope and Duration (although rarely Quality)
• Agile’s user-informed (bottoms-up) incremental deliveries respect the Iron Triangle’s limitations
© 2012 Copyright Galorath Incorporated 8
How Agile Allows Adjustments To The Iron Triangle?• Varying Scope is easy
• Negotiation between what is desired and what is possible
• Varying the Time to accommodate scope”• Depending upon what is required for delivery the
release date can be adjusted – makes no sense to deliver on a date if it’s not what is wanted
• Varying the Resources is a bit trickier• Can be difficult to find the right people
• This does not mean to just throw more people at the problem – remember Brooks Law
• Often reducing the number of people results in better quality and lower costs at a nominal increase in schedule
© 2012 Copyright Galorath Incorporated 9
Agile practices occur within the estimated project “envelope”.
This “strategic” estimate for the project:
On a “tactical” level, looks like this:
How Sprints Fit Into An Estimate
© 2012 Copyright Galorath Incorporated 10
A Focus on Maximizing Value
Priority Item1 feature a2 feature b3 feature c….
value
sprint
If the project is shut down earlymost of the value is already delivered!
© 2012 Copyright Galorath Incorporated 11
Mapping Of Traditional Activities
Agile sprints result in a deliverable product.
As a result, the labor mix is much higherthroughout the project.
{Analyst, Design, Code, Test, CM, Data Prep, Management, QC}
While most activities are blendedinto each sprint.
{Requirements, Analysis, Design, Detailed Design, Code, Unit Test, Integrate & Test, Program Test}
© 2012 Copyright Galorath Incorporated 12
This physical WBS:
Estimation Decomposition
May result in one long set of sprints:
Or simultaneous ones with multiple teams:
© 2012 Copyright Galorath Incorporated 13
Measuring Productivity
Agile Velocity Estimating’s Productivity
Velocity is tactical – “How much can we build in a sprint?”
Productivity is strategic – “How much can we build in a project?”
Velocity – “story points per sprint”
Productivity – “SLOC or function points per day or month”
Is this possible?
Velocity Productivity
© 2012 Copyright Galorath Incorporated 14
Metrics
A Story Point is an arbitrary (but intuitive) measure of a feature’s scale: {1,2,4,8,16…}, {1,2,3,5,8…}
A Function Point (FP) is a measure of a feature’s scale from a functional perspective.
Lines of Code (LOC) are a measure of a feature’s scale from a physical perspective.
Story Points can be measured in terms of Function Points or Lines of Code – and they wont vary by the team!
© 2012 Copyright Galorath Incorporated 15
Project Level Estimation
Project histories typically are sized inFunction Points (FPs) or Lines of Code (LOC)…
…and typically require FPs or LOCto produce estimates.
Estimation tool calibration
Alternative calibrations could use Story Pointsif *consistently defined across projects.
Velocity Productivity
* Consistency requiresall teams using identicallydefined story points –best of luck!
© 2012 Copyright Galorath Incorporated 16
Meanwhile…
While Story Points are a fine metric within sprints,conventional metrics (functional, lines, analogy) may
be better.
The (Conventional Estimation)
QualityResources Duration
Scope (features)
Conventional estimates have respectedthe Iron Triangle before it got a name.
© 2012 Copyright Galorath Incorporated 17
Estimation Is Dead!All Hail Estimation!• Sophisticated project estimates have always
respected the Iron Triangle
• What’s new is accounting for the effectof Agile affect upon delivery, functionality, and quality
QualityResources Duration
Scope (features)
• It is the responsibility of Agile implementers to reduce expectations of precision in estimates
“It’s better to be roughly right than precisely wrong!” - John Maynard Keynes
© 2012 Copyright Galorath Incorporated 18
User Story Defined
• A User Story is a simple statement about what a user wants to do with a feature and the value the user will gain.
• Consider a User Story as a thin vertical slice through the system.
• User stories are written from the user perspective in a way that can be easily understood.• Technical jargon is avoided.
• Acceptance Criteria is usually written at the same time.
• The Project Owner is responsible for the user stories• Written by the Sponsor
• Reviewed by the project team
• Usually written on cards• Story on the front
• Acceptance Criteria on the back
© 2012 Copyright Galorath Incorporated 19
Anatomy of a User Story
• A User Story identifies:• The User
• What the user wants to do with a feature
• Value gained by the user
• So a User Story can use the following format:
As a (user role)
I want (feature/achieve something)
So that (describe value)
• As a customer I want to track my order from the time I place it until it is delivered so that I know the status of my order at all times.
© 2012 Copyright Galorath Incorporated 20
Good User Stories • Bill Wake came up with the INVEST acronym to describe good
User Stories. This is a simple way to express User Story goodness.
• INVEST• Independent
• User stories should not be dependent on other stories.
• Negotiable• Don’t treat a User Story as a contract.• Less detail is better in most cases.• Some constraints are not negotiable.
• Valuable• Shows value to the user (subject of the story)
• Sized right• Enough detail to properly estimate• Small enough to estimate• Small enough to fit into a sprint
• Testable• Acceptance criteria should be apparent• This can be verified quickly by writing acceptance criteria on the back of the
card© 2012 Copyright Galorath Incorporated 21
22Ready for what’s next Booz Allen Hamilton
Function Point Components
Function points represent logical size, as opposed to physical size (like SLOC or objects)
Function points measure software size based on functionality requested by and provided to the end user
Estimating Agile Projects (Source: Vogt)
8
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Generate Early Estimates For Agile
Every Project Needs An Initial Estimate.. Agile Is Not Any Different
User Defined Sizing
Build Bottoms Up or..
Start Top Down
Manage Uncertainty of Early Estimation
Generate Estimates At Any Point In Development
Manage Sprints Effectively Through Re-estimation!
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Sprint or ReleaseBacklog
Full Life Cycle Estimateor
Sprint Planning Estimateusing
Multiple Team Velocitiesto
Identify Impact of Backlog
Full Life Cycle Estimateor
Sprint Planning Estimateusing
Multiple Team Velocitiesto
Identify Impact of Backlog
Estimate Quality Impacts
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Each Iteration Can Be Fine Tuned To Accommodate Complexities
Identify Probable Defects Before Sprint
Predict Impact on Schedule if Matrix
Teams
Recognize Impact Of Integration Early In Life Cycle
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Each Phase or Labor Category Can Be Modeled Independently
Calculate Effort for Component Integration
Identify Cost of Added Functionality Late in
Release
Model Integration Team Separately
Calculate Effort for Component Integration
Identify Cost of Added Functionality Late in
Release
Model Integration Team Separately
Total Ownership Costs Includes Cost Of On-Going Support
Sprint or ReleaseBacklog
Iteration to Build
CodeTest
Refactor
Delivered Functionality
Working System
n-Iterations per Release n-Iterations per Release Warranty & MaintenanceWarranty & MaintenancePlanningPlanning
User Stories, Use Cases, Business
Requirements, Etc.
Fixes, Enhancements, Sustainment
Defects & Unfinished Work
Collection of Functionality
Ability To Call Out Specific Items For Warranty/Maintenance
Identify Total Ownership Costs for the Software
Allows Independent Maintenance Team
Assumptions
Estimate Cost of: Corrective, Adaptive,
Perfective, and Enhancement support
Identify Total Ownership Costs for the Software
Allows Independent Maintenance Team
Assumptions
Estimate Cost of: Corrective, Adaptive,
Perfective, and Enhancement support
SEER Knowledge Bases Understand Flavors of Agile
© 2013 Copyright Galorath Incorporated 28
Special Parameter Settings Available for Agile
Two Agile Knowledge Bases
Agile FULL
•Assumes the development team is motivated, has strong programming skills, has previously performed an on an Agile project
•That the project will have a certified facilitator – such as a “Scrum Master.”
Agile Novice•Development teams first or initial attempt at Agile software development.
•Assumes the development team has little to nominal experience in an Agile process Or the team does not have a certified facilitator
•The learning curve for Agile will increase during the project life however initial velocity is not optimal.
•PM or Quality oversight during the implementation of this new methodology could be intrusive
Store User Stories in Database For Estimation Retrieval
© 2013 Copyright Galorath Incorporated 30
Backlog Planning Can Be Performed Using Stories or Analogies
Easy To Load All Stories For Initial Backlog
Planning
Easy To Load All Stories For Initial Backlog
Planning
Perform Sprint Planning By Teams
© 2013 Copyright Galorath Incorporated 31
Very Fast Approach For Early Release Planning
Select Only Stories For The Sprint
thenValidate That All The
Stories Can Be Completed During That Sprint
Select Only Stories For The Sprint
thenValidate That All The
Stories Can Be Completed During That Sprint
Use Story Points For Sizing
© 2013 Copyright Galorath Incorporated 32
Identify how many of each SP Count the team will
attempt
Ranges can be used to account for uncertainty
Identify how many of each SP Count the team will
attempt
Ranges can be used to account for uncertainty
Each Team Can Have a Unique Velocity
Enhanced Granularity At Kbase Level
© 2013 Copyright Galorath Incorporated 33
Estimate Should Be Modeled To Reflect Reality
Team A Is More experienced and working on more
complex component
Team B is new to Agile and working on
simple reports
User Defined Activities and Labor Categories
© 2013 Copyright Galorath Incorporated 34
Create Custom Naming for Life Cycle
Create Custom Naming for Labor Roles
Activities Can Be Weighted To Observed Contributions
Each Team Can Have Unique Labor Contributions
© 2013 Copyright Galorath Incorporated 35
Create Custom Distributions of Labor Based Upon Each Life Cycle Activity
Easy To Specify Who Does What and When
There Are Specific Parameters To Consider With Agile Estimates
• Requirements Formality
• Requirements Volatility
• Personnel Capabilities – Analyst and Programmers
• Familiarity with the Process
• Process Maturity
• Staffing Complexity
• Development System Volatility
• Automated Tools Usage
• Testing Level
• Quality Assurance Participation
Agile Things to Do
• Gauge the Organization:• Assess teams interactivity and motivation
• Teams familiarity with process
• What is the real role of QA
• Do they really have everyone in place
• Revisit the Estimate After One or Two Iterations• Repeat the first bullet!
• Pay Attention To Backlog • Could Indicate Process Immaturity…
• …but Is More Likely Requirements Volatility
Wrap Up - Estimating Agile
• About Agile• Remember – Emphasis is on delivered “stuff” not effort
or even schedule.
• Understand the Specific Method Being Used
• Whatever is not finished is moved to next Iteration
• When Using SEER for Software• Start with one of the Agile Knowledge Bases
• Adjust Parameters to Reflect Reality
• Change naming schemes to match method• Change both the Activity and applicable Labor names
• Calculate and redistribute labor by activity• This data is usually available from previous projects
• Use the proxy to estimate effort (for SCRUM)
Final Note
• When building an estimate for an Agile method, one needs to follow one important rule:
- Stay “Agile”