Contents
Status
This is a very rough draft. Not ready for comment.
Introduction
This scenario is based on the Reestimating use case. Refer to the EMS 1.0 Primer for other scenarios.
Estimation involves making assumptions about the project and using those assumptions to predict its future course. Predictions cannot usually be made with complete accuracy. We model the accuracy of the prediction as a probability distribution whose variance is a measure of its uncertainty, i.e. its investment risk.
As a project progresses through its lifecycle, we gain more information about it. We can use this newly gained information to make the estimates more accurate, i.e. less risky. It is therefore a best practice to reestimate the project at certain points in its lifecycle. As new estimates are made and approved, they become part of a new project baseline and are used to monitor metrics from that point on, until the project is reestimated again.
In a healthy project, the variance of an estimate should decrease over time. When the project finishes, all metrics, e.g. project duration, are known with certainty and so the variance of the estimate is zero.
We’ll illustrate the reestimation process by continuing on with the Tsunami 1.0 project example. Recall that the Tsunami 1.0 project is being carried out by a development team at BrainTwistors Corp. The team has decided to track several metrics during the project in order to assess their progress and the likelihood of that they will deliver the planned function on schedule with good quality. This means that they will establish lifecycle estimates for each of these metrics, measure these metrics as the project progresses, and compare the measurements with estimates.
The team uses an iterative development process with iterations of length 2 weeks, i.e 0.5 months. Since the project duration is 6 months, a total of 12 iterations are planned.
project_duration = 6 months
iteration_duration = 0.5 months
number_of_iterations
= project_duration / iteration_duration
= (6 months) / (0.5 months)
= 12
The team has decided to formally assess their progress at the end of each iteration and reestimate the lifecycle values of the metrics they are tracking based on their actual measurements to date. Ideally, the variance of each estimate will decrease each time it is reestimated.
The development team has decided to track their progress using several metrics including the rate at which the source code base is growing and changing, the rate at which planned features are completed and new ones requested, and the rates at which defects are found and fixed. In the following discussion we’ll focus on the source code growth rate measured in ESLOC.
When the Tsunami 1.0 project was initiated, the Guestimator 101 software estimation tool was used not only to estimate the cost but also to estimate the lifecycle values of the metrics that the team decided to track. These estimates were linked to the project plan so that they could be compared with the actual measurements. Measurements were also collected and linked to the project. The way that the team uses the estimates and measurements is described the the EMS 1.0 Primer: Monitoring and Controlling a Project scenario.
Let’s look in on the team at the end of iteration 6. The team has collected their measurements and the project manager, Priyanka Malhotra, has reviewed and approved them. The measurements could be collected either manually or automatically. After they are approved, the measurements become part of the project baseline and can be used to reestimate the project.
The team uses a project management tool, TaskPhocus, that maintains the project plans, tasks, features, defects, etc. and that has been configured to enact the iterative process used by the team, including the end of iteration reestimation process. The TaskPhocus user interface is not within the scope of the EMS 1.0 specification. It is described here purely for purposes of illustration. TaskPhocus does implement the REST services required for the reestimating scenario.
When Priyanka is satisfied that the end of iteration review has been completed, she marks this task as complete, and TaskPhocus responds by assigning the tasks associated with planning the next iteration. One of these tasks is to reestimate the project. This task gets assigned to BrainTwistor Corp.’s expert software estimator, Syd Ethan. Syd received as email telling him that Tsunami 1.0 is ready to be reestimated. The email contains the link to the reestimation task in TaskPhocus and the link to the Tsunami 1.0 project plan.
Syd launches Guestimator 101, invokes its Reestimate command, and enters the Tsunami 1.0 project URI when prompted. Guestimator 101 is rather primitive and doesn’t keep track of previous estimation sessions. It only maintains a database of past completed projects. A more sophisticated software estimation tool could keep track of past sessions and let the user select which project to reestimate without prompting for the project URI.
Guestimator 101 does a GET on the Tsunami 1.0 project URI and receives its representation, which now links to the measurements.
Insert XML of Project, Estimate, and Measurement here
Guestimator 101 uses the measurements to reestimate the lifecycle values of the metrics the team is tracking, including ESLOC. The lifecycle values for ESLOC have zero variance for the first 6 iterations since they are measurements and hence known with certainty. Guestimator 101 predicts the values to completion as triangular distributions, but now the variance of the last value, i.e. the value at the end of iteration 12, is much smaller than its variance when the project was initiated. Syd reviews the estimates and when he is satified, invokes the Send command. Guestimator 101 then does a POST of the new estimation run back to the project URI.
Insert XML of EstimationRun here
Syd goes back the email and clicks on the reestimation task link which launches the TaskPhocus Web user interface. Syd clicks on the Tsunami 1.0 project link and verifies that the new estimates have been received. He returns to the reestimation task in TaskPhocus and marks it as Done. This action triggers a notification to Priyanka who reviews the new estimates, and when satisified marks the reestimation task as Closed. These user interface details are beyond the scope of the EMS 1.0 specification and are given purely for purposes of illustration.
Now let’s fast forward to iteration 8. At this point in time the team has hit a snag. The rate at which defects are being fixed has dropped off and the project is accumulating a growing backlog of open defects. In this case Priyanka identifies the problem as a staffing shortfall due to several developers leaving to join a startup. Priyanka asks Syd to reestimate the project using two alternate sets of assumptions, namely to either reduce function and meet the schedule or the meet the function and extend the schedule. Guestimator 101 creates thes new estimation assumptions and POSTs them to the project. It then POSTs the two estimation runs back to the project URI.
Insert XML of EstimationAssumptions here
Summary of Resources and Services
Insert sequence diagram here.
Please enter your comments here:
This nicely raises a fundamental question about what may be a general OSLC question, related perhaps to the “list representation” question discussed last week: If one resource type (in the REST representation sense, not the person works on a project sense), such as Project, has a subordinate resource, such as ProjectEstimationHistory, does a change to the subordinate resource require a POST (in this example, PUT in others) directly to the subordinate resource, or a POST to the enclosing resource, which encapsultes the change in the subordinate resource? It’s especially interesting if the subordinate resource is (often??? depends on tool packaging) managed by a differerent tool from the enclosing resource like in this example. This will also apply (or maybe it’s just a related issue) to the “actuals” discussed—does the estimation tool do a GET on the project to get the information to count source code lines changed, or does it make a REST call to the source code configuration tool for this information (discovering the service interface for that tool, perhaps, from the project). So, personifying this, to get complex subordinate info from the project, do the tools ask (i.e. make REST calls to) the project for the information, or just ask the project who to ask?
Category:EMS Primer
