Lecture 9: Estimation and Scheduling

Question 1

Motivation: Some Facts about Estimates

Answer 1

• Nearly 2/3 of projects significantly overrun their cost estimates (Lederer and Prasad 1992)
• 64% of the features included in products are rarely or never used
• The average project exceeds its schedule by 100% (Extreme Chaos Paper, Standish Group, 2001).

Question 2

Challenges

Answer 2

• Incomplete knowledge about:
  
  • Project scope and changes
  • Prospective resources and staffing
  • Technical and organizational environment • Infrastructure
  • Feasibility of functional requirements
• Comparability of projects in case of new or changing technologies, staff, methodologies
• Learning curve problem.

Question 3

Components of an Estimation

Answer 3

• Cost
  
  • Personnel (in person days or valued in personnel cost)
    
    • Person day: Effort of one person per working day
  • Material (PCs, software, tools etc.)
  • Extra costs (travel expenses etc.)
• Scope
  
  • Number of requirements
  • Complexity of requirements
• Time
  
  • Development Time
  • Project duration
  • Dependencies
• Infrastructure (often forgotten)
  
  • Rooms, technical infrastructure, especially in offshore scenarios

Question 4

Estimating Personnel Cost

Answer 4

• Personnel type: Team leader, application domain expert, analyst, designer, programmer, tester…
• Cost rate: Cost per person per day
• 2 alternatives for cost rate:
  
  • Single cost rate for all types (no differentiation necessary)
  • Assign different cost rates to different personnel types based onexperience, qualification and skills
• Personnel cost: person days x cost rate.

Question 5

Estimating Development Time

Answer 5

• Development time is often estimated by the formula
  
  • Duration = Effort / People
• Problems with this formula:
  
  • A larger project team increases communication complexity which usually reduces productivity
• It is not possible to reduce duration arbitrarily by adding more people to a project
  
  • “Adding people to a late project makes it even later” – Frederick Brooks, The Mythical Man Months

Question 6

Basic Estimation Model

Answer 6

Parametric Data –> Model –> Estimate

Example:

• Size & Project Data
• System Model
• Software Process
• Effort
• Schedule
• Cost

Question 7

How do you Build an Estimation Model?

Answer 7

Insight + Historical Data + Meta Model of SW Process = Estimation Model

Question 8

Top-Down and Bottom-Up Estimation

Answer 8

• Two common approaches for estimations
  
  • Top-Down Approach
    
    • Estimate effort for the whole project
    • Breakdown to different project phases and work products
    • –> If you do not have a WBS
• Bottom-Up Approach
  
  • Start with effort estimates for tasks on the lowest possible level
  • Aggregate the estimates until top activities are reached
  • –> Preferred if you have a WBS and knowledgeable developers

Question 9

Methods for estimating cost and effort

Answer 9

Expert estimation

• Based on
  
  • Experience
  • Domain knowledge
• Exemplary methods:
  
  • Planning Poker
  • Delphi
  • Assessment meetings

Algorithmic estimation

• Based on:
  
  • Key performance indicators
  • Formulas
  • Metrics
• Exemplary methods:
  
  • Lines of Code (LOC)
  • COCOMO II
  • Aron
  • Function Points

Question 10

Expert Estimation

Answer 10

= Guess from experienced people

• No better than the participants
• Suitable for atypical projects
• Justification of the result difficult
• Important when no detailed estimation can be done (due
• to lacking information about scope)
• Works best if the estimates are for short term items.

Question 11

Lines of Code

Answer 11

• Traditional way for estimating application size
• Advantage: Easy to do
• Disadvantages:
  
  • Focus on developer’s point of view
  • No standard definition for “Lines of Code”
  • You get what you measure:
    
    • If LOC is the primary measure of productivity, programmers ignore reuse and refactorings
• Caspers Jones: The use of LOC metrics for productivity should be regarded as professional malpractice.

Question 12

COCOMO (COnstructive COst MOdel)

Answer 12

• Developed by Barry Boehm in 1981
• Top-down approach to estimate cost, effort and schedule of software projects, based on size and complexity of projects
• Assumptions:
  
  • Derivability of effort by comparing finished projects (“COCOMO database”)
  • System requirements do not change during development
  • Exclusion of some efforts (for example administration, training, rollout, integration).

Question 13

Calculation of Effort in COCOMO

Answer 13

• Estimate number of instructions
  
  • KDSI = “Kilo Delivered Source Instructions”
• Two constants describing the complexity of the project: A, B
• 3 levels of difficulty that characterize projects
  
  • Simple project (“organic mode”)
  • Semi-complex project (“semidetached mode”)
  • Complex project (“embedded mode”)
• Calculate effort
  
  • Effort = A * KDSI
• Calculate development time
  
  • Time = C * Effort
  • C, D = constants based on the complexity of the project
• Also called COCOMO I

Question 14

COCOMO II

Answer 14

• Revision of COCOMO I in 1997
• Provides three models of increasing detail
  
  • Application Composition Model: Estimates for prototypes based on GUI builder tools and existing components
  • Early Design Model: Estimates before software architecture is defined
  • Post Architecture Model: Estimates once architecture is defined
• Targeted for iterative software lifecycle models such Boehm’s spiral model (COCOMO I was based on the waterfall model)
• COCOMO II includes new equations for reuse •
  
  • Enables build vs. buy trade-offs
• COCOMO II also addresses team experience, developer skills and distributed development

Question 15

Problems with COCOMO

Answer 15

• Judgment required to determine the influencing factors and their values
• Experience shows that estimation results can deviate from actual effort by a factor of 4
  
  • -> Cone of Uncertainty
• Some important factors are not considered:
  
  • Skills of team members, travel, environmental factors, user interface quality, overhead cost

Question 16

Estimation Variability: Cone of Uncertainty

Answer 16

• Lessons learned in NASA Projects
  
  • At the beginning of a project, before requirements elicitation, estimates have an uncertainty of factor 4

Question 17

Problems with Traditional Estimation Techniques

Answer 17

• Focus on the completion of activities and not on the delivery of features
  
  • Customers get no value from the completion of activities J
• Wrong focus in schedule reviews
  
  • The reviewers look for overlooked activities, not for overlooked features
• When faced with overrunning a schedule, teams
  
  • attempt to save time by reducing quality
  • introduce change-control policies that constrain highly valuable changes in the software system.

Question 18

Planning Poker: An agile estimation approach

Answer 18

• Planning poker packages expert estimates into an enjoyable approach to estimating
• All the participants are estimators, in particular all the developers, not just the project manager!
• The estimation team should not have more than 10 people
  
  • If there are more than 10 people, create two or more estimation teams
  • The product owner participates in the game, but does not estimate
• Most important aspect of planning poker:
  
  • Estimates are arrived at by consensus building, not by looking at a crystal ball.

Question 19

Planning Poker Rules

Answer 19

1. Start: Each team member is given a set of cards
2. One person reads each of the items to be estimated
   
   • Examples of items: Functional requirements, user stories, scenarios, features, design goals, implementation of algorithms, TODOs
3. The team discusses each item individually
   The product owner can participate, but does not estimate
4. Each team member estimates the difficulty of the item and privately selects a card representing the estimate
5. After all team members have chosen their card, everyone shows their chosen card to the others at the same time
   If the team member’s estimates match, the estimate for this item is established (for now)
6. If estimates are not the same, the group discusses the differences
   Steps 4 to 6 are repeated until a consensus is reached.
   Important: Don’t Average During Planning Poker

Question 20

Advantages / Disadvantages of Planning Poker

Answer 20

Disadvantages:

• It is based on expert opinion
• When a same backlog is provided to another Scrum Team, it could come up with estimation that vary drastically different
• Estimation changes with the different skills and experience
• Team estimates while individuals are owners
• “What” factor when not well described makes it harder for the team to estimate.

Advantages:

• Group Estimating: Wisdom of the Crowd
• The conversation following the revealing of initial estimates is a great way to pool important issues

Question 21

Dependency Diagrams

Answer 21

• Example:
  
  • You are assigned a project consisting of 5 tasks
  • Each of these needs one week to be completed
  • How long does the project take?
• Another Example:
  
  • You are assigned a project consisting of 5 tasks
    
    • Task 1 has to be finished before any other tasks can start
    • Task 2 and 3 can be done in parallel, task 4 and 5 cannot
    • Task 5 depends on task 2
• Can the project be finished in 3 weeks, if each of the tasks takes a week to complete?
• What if 4 and 5 can be done in parallel, but 2 and 3 cannot?
• –> A dependency diagram is a formal notation that helps in the construction and analysis of complex schedules.

Question 22

Dependency Diagrams (Overview)

Answer 22

• Dependency diagrams consist of 3 elements
  
  • Event: A significant occurrence in the life of a project
  • Activity: Amount of work required to move from one event to the next
  • Span time: The actual calendar time required to complete an activity
    
    • Span time parameters: availability of resources, parallelizability of the activity
• Dependency diagrams are drawn as a connected graphs of nodes and arrows. Two commonly used notations are:
  
  • 1. Activity-on-the-arrow notation
  • 2. Activity-in-the-node notation.

Question 23

What do we do with these diagrams?

Answer 23

• Compute the project duration
• Determineactivitiesthatarecriticaltoensureatimely delivery
• Analyze the diagrams
  
  • To find ways to shorten the project duration
  • To find ways to do activities in parallel
• 2 techniques are used
  
  • Forward pass (determine critical path)
  • Backward pass (determine slack time).

Question 24

Critical Path and Slack Time

Answer 24

• Critical path
  
  • A sequence of activities that take the longest time to complete
  • The length of the critical path defines how long a project will take to complete
• Noncritical path
  
  • A sequence of activities that can be delayed and the project can still finish in the shortest time possible
• Slack time
  
  • The maximum amount of time that you can delay an activity and still finish your project in the shortest time possible.

Question 25

Analyzing Dependency Graphs

Answer 25

• Determination of critical paths
  
  • Compute earliest start and finish dates for each activity
  • Start at the beginning of the project and determine how fast you can complete the activities along each path until you reach the final project milestone
  • Also called forward path analysis
• Determination of slack times
  
  • Start at the end of your project, figure out for each activity how late it can be started so that you still finish the project at the earliest possible date
  • Also called back path analysis

Question 26

Definitions: Start and Finish Dates

Answer 26

• Earliest start date (ES)
  
  • The earliest date you can start an activity
• Earliest finish date (EF)
  
  • The earliest date you can finish an activity
• Latest start date (LS)
  
  • The latest date you can start an activity and still finish the project in the shortest time
• Latest finish date (LF)
  
  • The latest date you can finish an activity and still finish the project in the shortest time.

Question 27

Computation of Slack Times

Answer 27

• Slack time of an activity A:
  
  • STA = LSA - ESA
• Example:
  
  • STA4 = ?
  • STA4 = 3 - 2 = 1
• Slack times on the same path influence each other
• Example: When Activity 3 is delayed by 1 week, the slack time for activity 4 becomes 0 weeks.

Question 28

Path Types in Dependency Graphs

Answer 28

• Critical path
  
  • Any path in a dependency diagram, in which all activities have zero slack time
• Noncritical path
  
  • Any path with at least one activity that has a nonzero slack time
• Overcritical path
  
  • A path with at least one activity that has a negative slack time
  • Overcritical paths should be considered as serious warnings: Your plan contains unreal time estimates.

Question 29

Types of Dependencies

Answer 29

• Finish-to-start (FS)
  Task B cannot start until task A finishes
  
  • Example: Two tasks: Construct fence and Paint fence. Paint fence cannot start until Construct fence finishes. This is the most common type of dependency
• Start-to-start (SS)
  Task B cannot start until task A start
  
  • Example: Pour foundation and Level concrete. The task Level concrete can’t begin until Pour foundation begins
• Finish-to-finish (FF)
  Task B cannot finish until task A finishes.
  
  • Example: Add Wiring and Inspect Electrical. Inspect Electrical can’t finish until Add Wiring finishes
• Start-to-finish (SF)
  
  • Task B cannot finish until task A starts.
  • This dependency can be used for just-in-time scheduling up to a milestone.

Question 30

Dependency constraints

Answer 30

• As Soon As Possible (ASAP)
  
  • Schedule the task as soon as possible without any other restrictions (Flexible constraint)
• Start No Earlier Than (SNET)
  
  • Specify the earliest date for a task to start. The task cannot start before that date.
• Start No Later Than (SNLT)
  
  • Specify the latest possible date for a task to begin. The task cannot be pushed to start after that date.
• Must Start On (MSO)
  
  • The task must start on that exact date (Inflexible constraint).
• As Late As Possible (ALAP)
  
  • Schedule the task as late as possible without any other restrictions (Flexible constraint)
• Finish No Earlier Than (FNET)
  
  • Specify the earliest date for a task to end. The task cannot end before that date.
• Finish No Later Than (FNLT)
  
  • Specify the latest possible date for a task to end. The task cannot be pushed to end after that date.
• Must Finish On (MFO)
  
  • The task must finish on that exact date (inflexible constraint).

Question 31

Frequently used formats for schedules

Answer 31

• Milestone View
  
  • A table that lists milestones and the dates on which you plan to reach them
• Activities View
  
  • A table that lists the activities and the dates on which you plan to start and end them
• Gantt chart View
  
  • A graphical illustrating on a timeline when each activity will start, be performed and end
• Combined Gantt Chart and Milestone View
  
  • The Gantt Chart contains activities as well as milestones
• PERT Chart
  
  • A graphical representation of task dependencies and times
• Burndown Chart
  
  • A graph showing the number of open tasks over time.

Question 32

Milestone View (Key-Events Report)

Answer 32

Good for introduction of project and high executive briefings

Date

August 26 October 16 October 26 November 7 November 20 Nov 26

Dec 11

Milestone

Project Kickoff (with Client) Analysis Review
System Design Review Internal Object Design Review Project Review (with Client) Internal Project Review Acceptance Test (with Client)

Question 33

Activities View

Answer 33

Good for documentation and during developer meetings

Date

Jul 17 - Aug 23 Aug 26 - Sep 24 Sep 11 - Oct 8 Oct 9 - Oct 26 Oct 28 - Nov 7 Nov 8 - Nov 20 Nov 22 - Dec 4 Dec 4 - Dec 10 Dec 11- Dec 18

Project Phases

Preplanning Phase Project Planning Requirements Analysis System Design

Object Design
Implementation & Unit Testing

System Integration Testing System Testing Post-Mortem Phase

Question 34

Gantt Chart

Answer 34

Easy to read

Question 35

Gantt Chart with milestones

Answer 35

Good for reviews

Question 36

Two Types of Gantt Charts

Answer 36

• Person-Centered View
  
  • To determine people‘s
• Activity-Centered View
  
  • To identify teams working together on the same tasks work load

Question 37

PERT Chart

Answer 37

• PERT stands for “Program Evaluation and Review Technique”
• Algorithm:
  
  • Assign optimistic, pessimistic and most likely estimates for the span times of each activity
  • Compute the probability that the project duration falls within specified limits
• The first version of PERT did not take cost into consideration but was later extended to cover cost as well.
• • Good for clear illustration of task dependencies

Question 38

Burndown Chart

Answer 38

• Good for progress reports (non-linear progress), project controlling.

Question 39

Reasons for Schedule Overruns

Answer 39

1. Activities don’t finish early
2. Lateness is passed down the schedule
3. Activities are not independent
4. Features are not developed by priority
5. Uncertainty is ignored.

Question 40

1. Activities don’t finish early

Answer 40

• If there is a Gantt Chart that says an activity is expected to take 5 days, the programmer will make sure that the activity takes 5 days
• There is also a tendency that one expands the scope of a task so that if fills the estimated time
• Parkinson’s Law (1993):
  
  • “Work expands so as to fill the time available for its completion”

Question 41

2. Lateness is passed down the schedule

Answer 41

• Because traditional plans are activity based, they focus on the dependencies between activities
• Example:
  
  • Assume that task Tn depends on a set of other tasks T1, T2, …Tn-1
  • Starting Tn early means that all the tasks T1, T2,… have to be finished early or at least in time
  • We already know that activities don’t finish early (see previous slide)
    
    • An early start of Tn requires a combination of things to go well (T1, T2, … finish in time)
    • A late start of Tn requires only that one of the dependent tasks does not finish in time.

Question 42

3. Activities are not independent

Answer 42

• Activities are independent when the duration of an activity does not influence the duration of another activity
  
  • Example: In building a house, the amount of time to excavate a basement is independent from the time it takes to paint the walls
• In software most of the activities are inter-dependent:
  
  • Example: Writing the User Interface. If the first screen takes 50% longer than estimated, there is a good chance that the other screens also take longer than planned
• When activities are dependent on each other, variations in completion time do not balance out:
  
  • I cannot say “Yes, I was late with this task this time, but I’ll make it up in the remaining tasks”

Question 43

4. Features are not developed by priority

Answer 43

• Many traditional planning approaches assume that all the identified activities will be completed
  
  • If all work will be completed, then project customers don’t have any preference about the sequence in which work is done
  • The work described in traditional SPMPs is often not prioritized by its value to the user/customer
  • This means, the development team is working on features that have no high value to the user/customer
  • At the end of the project the team is scrambling to meet the schedule by dropping features
  • Because there was no attempt to work on features in order of priority, some features with great value are dropped and cannot be delivered.

Question 44

5. Uncertainty is ignored

Answer 44

• Traditional approaches ignore uncertainty
• Many managers still adhere to “waterfall thinking”:
  
  • They assume that the initial requirements analysis leads to a complete specification of the product.
  • They also assume that users will not change their minds nor come up with new needs during the project
• Better approach: Allow for short iterations
  
  • Short iterations reduce the uncertainty what the product should be (requirements elicitation), because the user/customer has a working software every few weeks to play with
  • Short iterations also reduce the uncertainty of how to develop the product (planning), because missing tasks can be added to the plan and bad estimates can be corrected.

Question 45

Scheduling Heuristics

Answer 45

1. How to develop an initial project schedule
2. How to shorten the project duration
3. Mistakes when preparing schedules
4. How to identify when a project goes off-track (actual project does not match the project plan).
5. How to become a good software project manager

Question 46

1. How to develop an Initial Project Schedule

Answer 46

• Identify all your activities
• Identify intermediate and final dates that must be met
• Assign milestones to these dates
• Identify all activities and milestones outside your project that may affect your project’s schedule
• Identify “depends on” relationships between the activities
• Draw a dependency diagram for the activities and relationships
• Determine critical paths and slack times of noncritical paths.

Question 47

2. How to shorten the project duration

Answer 47

• Recheck the original span time estimates
  
  • Ask other experts to check the estimates
  • Has the development environment changed? (desktop vs. mobile development)
• Consider different strategies to perform the activities
  
  • Consider to buy a work product instead of building it (Trade-off: Buy-vs.-build)
  • Consider an external subcontractor instead of performing the work work internally.
• Hire more experienced personnel to perform the activities
  • Trade-off: Experts work fast, but cost more
• Try to find parallelizable activities on the critical path
  
  • Continue coding while waiting for the results of a review
  • Risky activity, portions of the work may have to be redone
• Develop an entirely new strategy to solve the problem.

Question 48

3. Mistakes when preparing schedules

Answer 48

3.1. Using Fudge Factors

• Fudge factor
  
  • A fudge factor is the extra amount of time you add to your best estimate of span time “just to be safe”
    
    • Example: Many software companies double their span time estimates
• Don’t use fudge factors!
  
  • If an activity takes 2 weeks, and you add a 50% fudge factor, chances are almost zero that it will be done in less then 3 weeks
    
    • Reason: Parkinson’s law.

3.2. The “Backing in” Mistake

• Backing In:
  
  • You start at the last milestone of the project and work your way back toward the starting milestone, while estimating durations that will add up to the available time
• Problems with Backing in
  
  • You probably miss activities because your focus is on meeting the time constraints rather than identifying the required work
  • Your span time estimates are based on what you allow activities to take, not what they actually require
  • The order in which you propose activities may not be the most effective one
• Better:
  
  • Start with estimating the required times and then try to shorten the project duration.

Question 49

4. How to identify when a project goes off- track

Answer 49

• Determine what went wrong: Why is your project got off track?
  
  • Behind schedule
  • Overspending of resource budgets
  • Not producing the desired deliverables
• Identify the reasons.

Question 50

5. How to become a better project manager

Answer 50

• Don’t assume anything
  
  • Find out the facts
  • Use assumptions only as a last resort
  • With every assumption comes a risk that you are wrong
• Communicate clearly with your people
  
  • Being vague just increases the chances for misunderstanding
• Acknowledge performance
  
  • Tell the person, the person’s boss, team members, peers when they are doing well
• View your people as allies not as adversaries
  • Focus on common goals, not on individual agendas
  • Make people comfortable by encouraging brainstorming and creative thinking
• Be a manager and a technical leader
  
  • Deal with people as well as with deliverables, processes, models and systems
  • Create a sense of vision and excitement.

Question 51

Summary

Answer 51

• Estimation is a basis for the decision to start, plan and manage a project
• Estimating software projects is a difficult project management function, however:
  
  • Few software organizations have established formal estimation processes
  • The estimation technique influences the results - must be used with care (Cone of Uncertainty)
• Cost should not be estimated before a WBS is performed
  
  • Dependency graph = WBS + dependencies.
  • Schedule = Dependency graph + time estimates
• Critical Path Analysis
• Many reasons for scheduling overruns
• Scheduling Heuristics à How to become a good manager

Question 52

Why is estimation a hard task?

Select one or more:

a. There is not enough knowledge about the developing environment
b. Team members get punished for wrong estimates
c. Everyone has experience in similar projects
d. Discussions may take long time

Answer 52

a, d

Question 53

Top-down estimation is used

Select one or more:

a. To start with effort estimates for tasks on the lowest possible level
b. When there is no Work Break Down Structure for the project
c. If we want to estimate the overall project
d. When team members have worked in previous similar projects

Answer 53

b,c

Question 54

What does the Cone of Uncertainty show?

Select one or more:

a. Many characteristics of a project become clear only after some time
b. Estimation should be done at the end of the project
c. There is not enough knowledge about the project at the beginning
d. Estimation can be easily done at the beginning of a project

Answer 54

a, c

Question 55

PERT-based estimation

Select one or more:

a. Uses T-shirt sizes as estimation values
b. Is done before every sprint
c. allows to use multiple estimates per project activity

Answer 55

c

Question 56

What should be considered when estimating?

Select one or more:

a. Team members preferences
b. The locations where development takes place
c. Project duration
d. Project budget

Answer 56

b,c,d