estimating agile projects with seer for software new … agile projects wit… · ·...

Estimating Agile Projects Using

SEER for Software

Copyright Galorath Incorporated 2013 1

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

You Probably Knew SEER for Software Supported These Methodologies

Salvage

RUP

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!


QualityResources Duration

Scope (features)

Estimating An Agile Project


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


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


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


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!


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}


This physical WBS:

Estimation Decomposition

May result in one long set of sprints:

Or simultaneous ones with multiple teams:


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


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!


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!


Meanwhile…

While Story Points are a fine metric within sprints,conventional metrics (functional, lines, analogy) may

be better.

The (Conventional Estimation)


Scope (features)

Conventional estimates have respectedthe Iron Triangle before it got a name.


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


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


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


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.


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


Iteration to Build

CodeTest

Refactor


Working System



Requirements, Etc.




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!


Iteration to Build

CodeTest

Refactor


Working System



Requirements, Etc.





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


Iteration to Build

CodeTest

Refactor


Working System



Requirements, Etc.




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


Iteration to Build

CodeTest

Refactor


Working System



Requirements, Etc.




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


Iteration to Build

CodeTest

Refactor


Working System



Requirements, Etc.




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


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


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


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


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


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


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


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”

Contact:

[email protected]

+1-310-414-3222

www.galorath.com

estimating agile projects with seer for software new … agile projects wit… · ·...

Documents