avoiding the time trap schedule value capabilities the user finds valuable constraints (cost,...

1

10/12/2015

© 2015 Carnegie Mellon University


Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

Avoiding the Time TrapTimothy A. Chick

2

Avoiding the Time TrapOctober 2015


The time trap

Time that does matter

What makes “task” time so special

Topics

2

10/12/2015


3



The Time Traps

The Agile ApproachThe Traditional Approach

Scope

ScheduleCost

Value

Capabilities the user finds valuable

Constraints

(cost, schedule, scope)

Quality

Deliver a reliable product by

adapting to customer’s needs

How is time measured?

How are schedules derived?

What do the two approaches have in common?

Ordinary time/money vs. story points/velocity

Durations based on resource availability vs. sprint/time box and

team’s velocity

A derived cost is needed to answer the

question, “Do I have enough money to

build a minimally useful item?”

4



With either approach you must account for labor. Two options are available:

• Tracking the employees’ ordinary time, which is in essence a proxy for cost

• Associating employees’ salaries with projects

While using ordinary time or tracking salaries are very useful methods for accounting and payroll purposes, they are nearly impossible to use for creating accurate estimates or precisely tracking projects.

Why?

Do I have enough money?

3

10/12/2015


5



Unrelated activities are included.

• Includes a mixture of activities that contribute to costs, but are not directly related to project deliverables.

Detailed estimating is difficult to accomplish.

• Accounting systems do not generally track time at the level necessary

for bottom-up, detailed estimating.

Precise project tracking is not supported by the data.

• The time data captured does not support the precise tracking that knowledge workers need to be repeatedly successful.

Why Ordinary Time Doesn’t Work

6



The Traditional Time Trap

The assumption of a relationship between effort and duration is fundamental to traditional project planning and tracking techniques.

Data shows that there is no correlation between the duration of a work package and the actual effort required to complete it, for knowledge-based efforts.

• 89 software development

and knowledge-based

projects reported to the SEI

through its Partner

Network.

• Projects started between

July 2000 and July 2012

and had an average project

duration of 119 calendar

days, with a team size of

less than 20 people.

• Duration of work packages

< 20 days from open to

close.

4

10/12/2015


7



The use of story points and velocity (number of story points achieved in a sprint) are simply proxies for cost and schedule.

• Effort is performed using an iterative, time-boxed approach.

• Past performance is used to predict how many stories points can be implemented per sprint.

Problems with relying solely on story points

• Story points and velocity are subjective measures that are calibrated by each team based on

previous team performance.1

• Team membership changes

• The type of work and skills required changes over time

• Estimates are biased.2

• Not based on actual historical data

• Number can easily be influenced

• The use of story points is not objective and cannot define a standard practice for estimation

of software size.3

• The definition of a story point varies between teams

The Agile Time Trap

1. Moser, R., Pedrycz, W., Succi , G. 2007. Incremental effort prediction models in Agile Development using Radial Basis Functions. Proc. 19th International Conf. on Software Engineering & Knowledge Engineering (Boston, MA, USA, July 9-11, 2007), SEKE'07, pp. 519-522.

2. N.C. Haugen, “An empirical study of using planning poker for user story estimation,” Minneapolis, MN, Agile 2006 Conference Proceedings

3. Javdani, T., Zulzalil, H., Ghani, A., Sultan A., Parizi, R. 2012. “On the Current Measurement Practices in Agile Software Development,” IJCSI, Vol. 9, Issue 4,No 3, July 2012

8



The Basic Planning Framework

Regardless of whether you are using a traditional, agile, or hybrid approach to planning and tracking, you need to be able to represent cost and schedule.

5

10/12/2015


9



Task time is defined as the actual time spent working on a specific task in the plan.

To determine task time, each individual working on the team is responsible for tracking the time spent working on each specific task they are assigned in the plan.

Time That Matters – Task Time

10



Actual Versus Planned Task Time for Completed Projects

There is a very strong correlation

between the planned and actual

task time required to implement

an individual work package.

This high correlation enables

very effective bottom-up

estimating

Data comes from 113 different

development projects, which

reported their results to the SEI

through its Partner Network.

All projects in the data set used

the same definition of task time

and planning framework.

.

6

10/12/2015


11



Actual Task Time Versus Plan Task Time

The use of task time in creating accurate estimates.

It plots actual task time against planned task time, in hours, for completed projects.

It demonstrates that there is a strong correlation between the bottom-up estimates for a

project and the actual task time spent on the project.

12



Overcoming Deficiencies

Traditional Approach

Task time can be used to overcome the short-comings of using ordinary time or financial information alone to determine when a project will be completed.

Once you can determine when a project will be completed using a given set of resources, you can also determine cost.

Agile Approach

Task time can be used in place of a subjective story points approach to provide an objective measurement which can be used as a standard estimating practice across teams and organizations.

7

10/12/2015


13



Using historical actual task time, a relative table can be created for estimating future work.

The table organizes your historical data into categories of types and ranges.

You can then refer to the table to quickly develop estimates for your user stories in your plan.

Applying Task Hours in Agile

VS S M L VL Issues

closed

Portal Platform (summary) 0.21 0.78 2.85 10.48 38.46 379

A Portal 0.76 2.00 5.25 13.80 36.27 5

Authorization/Authentication 0.98 2.01 4.13 8.49 17.46 11

B Portal 0.24 0.82 2.76 9.28 31.23 75

C Portal 0.08 0.48 2.73 15.65 89.58 39

Deployment 0.11 0.41 1.53 5.77 21.79 25

Liferay 0.23 0.86 3.28 12.43 47.17 66

M Portal 0.50 1.43 4.13 11.93 34.41 37

Middleware 0.20 0.82 3.26 12.99 51.82 30

Other 1.04 2.24 4.82 10.36 22.25 4

Requirements 0.80 1.96 4.81 11.81 28.96 31

R Portal 0.24 0.78 2.56 8.41 27.60 25

Testing 0.47 1.34 3.83 10.94 31.26 14

Viewflash 4.07 6.29 9.74 15.07 23.32 3

V Portal 0.71 1.52 3.25 6.95 14.87 14

14



A relative table is constructed using historical data on the effort of different components or effort types that you have developed in the past.

From the data:

1. Calculate the mean (x).

2. Calculate the standard deviation (s).

Constructing a Relative Table

Very Small

Small

Medium

Large

Very large

�̅ � 2�

�̅ � �

�̅

�̅ � �

�̅ � 2� MSVS L VL

8

10/12/2015


15



The Planning Game

16



Team Velocity Using Task Hours

Using actual data, you can determine what the velocity should be for the next sprint, even with changing and part-time team members.

Specialized resources can now move between teams without having to reset velocity calculations (project team membership should still stay relatively stable in order to maintain tacit knowledge).

Time-boxes can also be variable lengths based on project/customer goals and objectives.

Last 4 week sprint period.

Hours spent on Project

Average Hours Logged Per Week on Project

Hours spent overall

Average Hours Logged Overall

Amy 10.00 3.33 14.50 3.63

Brent 23.99 8.00 23.99 8.00

Nathan 87.42 21.86 87.42 21.86

Kim 12.46 6.23 13.08 6.64

Total 133.87 39.42 138.99 40.13

9

10/12/2015


17



The Project

Release 1 Release 2 Release n

Project Planning Example

Kick-off S

R

S

R

S

R

S

R

S

R

S

R

S

R R

A sprint is a time-boxed planning period.

The current sprint is planned in granular detail by the team as they are about to execute sprint.

Future sprints are road mapped during the initial planning by the Project Lead and PMO, but not with

the detail that the current sprint is planned. Road maps evolves with the project.

Releases are project-dependent. Sprints are based on the team’s cadence, and product delivery is

on demand. A sprint usually ranges from 2-6 weeks in duration.

Each sprint begins with a detailed plan and ends with a retrospective.

Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint n

R

S Re-plan

Retrospective

18



What Makes Task Time so Special?

Task time represents the project’s value chain and ignores the other activities, which skew predictability.

A value chain is the set of tasks directly associated with a work package that is carried out to create value for the customer or end user. These are the actual tasks that are part of the team’s plan.

Effort reports apply to both support activities and primary tasks.

Task time applies only to the primary tasks of a team’s value chain.

New Feature Design

Code and Unit Test

Integrate Features and

Bug Fixes

User Documentation

Build and Deliver

Release

Meetings – Email - Administrative

Human Resources

Training

Infrastructure

Su

pp

ort

Acti

vit

ies

Primary Tasks

10

10/12/2015


19



Understanding Variability

While the cost of project members can be predictable, the amount of task time individuals are able to commit to a project’s value chain is highly variable.

Understanding the variability at the individual and team level is key in producing accurate estimates and for precise status tracking.

Task time is measured in hours or minutes. Interrupt time, or off-task time, is not included in the time measure for a task.

Off-task time is not measured or tracked since it does not contribute to meeting the stated project goals.

20



Why do we focus our plans only on value?

http://www.youtube.com/watch?v=zc8zCSQxBhM

11

10/12/2015


21



We need to schedule our important task or else they won’t fit into the bucket.

It is not to say that if we put the big rocks in first, the pebbles will still fit around the edges. Some just won’t fit.

“Urgent” things keep coming up and these pebbles can get in the way of achieving what is important. Not everything urgent is important.

Without building a detailed plan and tracking our progress against it, the important tasks will slip due to the urgent pebbles, mandatory sand, and overflowing distractions.

Why do we plan our tasks?

22



NAVOCEANO Project Sponsor Survey Results

All projects in the survey used task-time and an Agile planning and tracking framework.

12

10/12/2015


23



Understanding the dynamics of your process in a quantifiable way provides these benefits:

• Increases the accuracy of estimates

• Improves reliability of status reporting

• Raises perceived customer quality and satisfaction

Task-time is an accurate, reliable, and repeatable measure of time.

The use of ordinary time or story points does not adequately meet the intended purposes of such measures.

Summary

24



Reference Article:

“Not All Time Matters: Be Sure to Count What Does.” CrossTalk, July/August 2015:

http://www.crosstalkonline.org/storage/issue-archives/2015/201507/201507-Chick.pdf

Questions?

13

10/12/2015


25



Contact Information

Timothy A. Chick

Senior Engineer

Telephone: +1 412-268-1473

Email: [email protected]

U.S. Mail

Software Engineering Institute

Customer Relations

4500 Fifth Avenue

Pittsburgh, PA 15213-2612

USA

Web

www.sei.cmu.edu

www.cert.org

Customer Relations

Email: [email protected]

Telephone: +1 412-268-5800

SEI Phone: +1 412-268-5800

SEI Fax: +1 412-268-6257

26



Copyright 2015 Carnegie Mellon University and IEEE

This material is based upon work funded and supported by the Department of Defense under Contract No.

FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE

MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING,

BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY,

EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON

UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This material has been approved for public release and unlimited distribution.

This material may be reproduced in its entirety, without modification, and freely distributed in written or

electronic form without requesting formal permission. Permission is required for any other use. Requests for

permission should be directed to the Software Engineering Institute at [email protected].

Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University.

DM-0002796

avoiding the time trap schedule value capabilities the user finds valuable constraints (cost,...

Documents