Estimating Agile Projects Using SEER for Software - Galorath

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 Best practice: Temper with “outside view”

• Most pronounced for new initiatives 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

•

More

Poorly constructed user stories may require modifications

© 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

Defects & Unfinished Work

User Stories, Use Cases, Business Requirements, Etc.

Test

Code

Refactor

Collection of Functionality

Planning

Sprint or Release Backlog

Iteration to Build

Delivered Functionality

n-Iterations per Release

Working System

Fixes, Enhancements, Sustainment

Warranty & Maintenance

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 Scope (features)

Quality Resources

•

Duration

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

Estimating An Agile Project •

The Agile Manifesto was a defense of the “Iron Triangle”

•

The “outer envelope” of a project still requires an estimate

Scope (features)

Quality Resources

Duration

•

The size of a project’s Iron Triangle is estimated by 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

How Sprints Fit Into An Estimate Agile practices occur within the estimated project “envelope”. This “strategic” estimate for the project:

On a “tactical” level, looks like this:


10

A Focus on Maximizing Value

Priority 1 2 3 ….

Item feature a feature b feature c

value

If the project is shut down early most of the value is already delivered!

sprint © 2012 Copyright Galorath Incorporated

11

Mapping Of Traditional Activities Agile sprints result in a deliverable product.

As a result, the labor mix is much higher throughout the project. {Analyst, Design, Code, Test, CM, Data Prep, Management, QC}

While most activities are blended into each sprint. {Requirements, Analysis, Design, Detailed Design, Code, Unit Test, Integrate & Test, Program Test}


12

Estimation Decomposition This physical WBS:

May result in one long set of sprints:

Or simultaneous ones with multiple teams:


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

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 in Function Points (FPs) or Lines of Code (LOC)… Estimation tool calibration

…and typically require FPs or LOC to produce estimates. Alternative calibrations could use Story Points if *consistently defined across projects. * Consistency requires all teams using identically defined story points – best of luck!

Velocity © 2012 Copyright Galorath Incorporated

Productivity 16

The (Conventional Estimation) Conventional estimates have respected the Iron Triangle before it got a name. Scope (features)

Quality Resources

Duration Meanwhile…

While Story Points are a fine metric within sprints, conventional metrics (functional, lines, analogy) may be better. © 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 effect of Agile affect upon delivery, functionality, and quality

Scope (features)

Quality Resources

•

Duration

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

Estimating Agile Projects (Source: Vogt) Function Point Components Function points measure software size based on functionality requested by and provided to the end user

Function points represent logical size, as opposed to physical size (like SLOC or objects)

Ready for what’s next

8

Booz Allen Hamilton

22

Generate Early Estimates For Agile

User Defined Sizing Defects & Unfinished Work


Test

Code

Build Bottoms Up or..

Refactor


Planning


Iteration to Build

Start TopWorking Down System





Manage Uncertainty of Early Estimation

Every Project Needs An Initial Estimate.. Agile Is Not Any Different

Generate Estimates At Any Point In Development

Full Life Cycle Estimate or Test Code Sprint Planning Estimate using Refactor Multiple Team Velocities Sprint orSprint or Release to Release Iteration to Working Backlog Delivered Backlog Build System Functionality Identify Impact of Backlog Warranty & Maintenance n-Iterations per Release Defects & Unfinished Work



Planning


Manage Sprints Effectively Through Re-estimation!

Estimate Quality Impacts Identify Probable Defects Before Sprint

Defects & Unfinished Work


Test

Code

Refactor


Planning


Iteration to Build

Predict Impact on Schedule if Matrix Teams Delivered Functionality


Working System



Each Iteration Can Be Fine Tuned To Accommodate Complexities

Recognize Impact Of Integration Early In Life Cycle Calculate Effort for Component Integration Defects & Unfinished Work

Identify Cost of Added Functionality Late in Test Code Release


Model Integration Refactor Team Separately Collection of Functionality

Planning


Iteration to Build



Working System



Each Phase or Labor Category Can Be Modeled Independently

Total Ownership Costs Includes Cost Of On-Going Support Identify Total Ownership Costs for the Software Defects & Unfinished Work


Allows Independent Maintenance Team Test Code Assumptions Refactor


Planning

Estimate Cost of: Sprint or Corrective, Adaptive, Release Iteration to Delivered BacklogPerfective, Build and Functionality n-Iterations per Release Enhancement support

Working System



Ability To Call Out Specific Items For Warranty/Maintenance

SEER Knowledge Bases Understand Flavors of Agile

Special Parameter Settings Available for Agile © 2013 Copyright Galorath Incorporated

28

Two Agile Knowledge Bases Agile FULL

Agile Novice

•Assumes the development

•Development teams first or initial attempt at Agile software 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.”

•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

Easy To Load All Stories For Initial Backlog Planning

Backlog Planning Can Be Performed Using Stories or Analogies © 2013 Copyright Galorath Incorporated

30

Perform Sprint Planning By Teams

Select Only Stories For The Sprint then Validate That All The Stories Can Be Completed During That Sprint

Very Fast Approach For Early Release Planning © 2013 Copyright Galorath Incorporated

31

Use Story Points For Sizing

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 © 2013 Copyright Galorath Incorporated

32

Enhanced Granularity At Kbase Level

Team A Is More experienced and working on more complex component

Team B is new to Agile and working on simple reports

Estimate Should Be Modeled To Reflect Reality © 2013 Copyright Galorath Incorporated

33

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 © 2013 Copyright Galorath Incorporated

34

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 © 2013 Copyright Galorath Incorporated

35

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