Work Breakdown Structure¶

The LSST WBS is defined in LPM-43 (see also LPM-44 for an extended—but not universally illuminating—definition of what each level of the breakdown consists of).

The WBS provides a hierarchical index of all hardware, software, services, and other deliverables which are required to complete the LSST Project. It consists of alphanumeric strings separated by periods. The first component is always “1”, referring the LSST Construction Project. “02C” in the second component corresponds to Data Management Construction. Subdivisions thereof are indicated by further digits. Subdivisions at this level correspond to teams within the DM project. Thus:

These subdivisions are referred to as the third level WBS. Often, they are quoted without the leading “1” (e.g. “02C.01”), but, even in this form, they are referred to as “third level”.

All of these third level WBS elements are subdivided, forming a fourth level. The fourth level always contains a “00” element, which is used to capture management and Level of Effort Work, and may contain other fourth level, or even deeper, structure. Nodes in the WBS tree are referred to as elements.

Organization Breakdown Structure¶

In parallel with the WBS, we have an OBS, which assigns each institution involved in the project a unique numeric identifier. Those directly relevant to DM are:

The Control Account Manager¶

A control account is the intersection between the WBS and the OBS. Each control account falls under the purview of a CAM. Typically within DM, a single CAM is responsible for the whole of a third level WBS. That is, the manager at the lead institution for a particular component is responsible for all work performed on that WBS element, even if that work is performed at another institution.

Labor Costs¶

Our methodology is designed to avoid exposing individual salaries to the wider project. Therefore, when calculating labor costs for earned value purposes, we do not rely on a known cost per individual. Instead, all staff are assigned to one of a small number of types (scientist, senior scientist, developer, senior developer), each of which is assigned a nominal cost level which does not vary between individuals, or, indeed, across institutions. This nominal cost does not correspond to a particular individual, but is a broadly defined expectation.

Variance Narratives¶

Every month, the eCAM tool is updated from PMCS to reflect the latest earned value status. If either schedule or cost variance (SV or CV) is more than -$100k, you will be required to provide a “narrative”. This is divided into two parts: you must explain why the variance arose, and what action will be taken to correct it (e.g. slipping work into the future, or diverting resources from elsewhere to make up the shortfall). The narrative is entered directly into eCAM.

Variance is calculated on a monthly basis; variance narratives are due in the second week of the calendar month following that to which they apply (refer to the Standard Reporting Cycle for details).

Level of Effort Work¶

The implicit assumption in the earned value technique outlined above is that all work corresponds to a specific deliverable. However, parts of our work do not: every member of the team will find it necessary to attend meetings or take part in other activities which do not directly map to deployed code. This may be particularly the case for technical managers or others in leadership roles within the project. This work is referred to as LOE: it is assumed to earn value simply through the passage of time.

LDM-465 provides a detailed definition of the types of work it is permissible to regard as LOE. In general, we strive to minimize the fraction of our effort which is devoted to LOE activities and favour those which are more directly accountable.

The assumption encoded in LDM-465 is that developers will spent 30% of their time on LOE type activities, and the remaining 70% of their effort is tracked against concrete deliverables.

All LOE work should be invoiced to the “00” fourth-level WBS element (1.02C.03.00, 1.02C.04.00, etc), which is reserved for “management engineering and integration”. Per the effort estimation procedure, this means that at least 30% of every individual’s time will be invoiced to the 00 element.

Earned Value and Planning Packages¶

A planning package has a duration and a staff assignment (it is “resource loaded”). Given a (nominal) cost per unit time of the staff involved (see Labor Costs), this translates directly to a BCWS.

During Short Term Planning, effort is drawn from the budget embodied in the planning packages to generate the cycle plan, described in terms of epics: see Defining Epics for details. Each epic itself has a particular budget. This budget is subtracted from that available in the planning package at the point when the epic is defined.

At any given time, the BCWP of a planning package consists of the sum of the BCWP of all epics derived from that package which have been marked complete, together with the fractions of value earned from all epics currently in progress.

An example may serve to illustrate.

Planning package P is baselined to start at the beginning of F17 and run through to the end of F18, i.e. a total of three cycles, or 18 months. It has two members of staff—A and A— assigned to it full time. Both share the same nominal cost of $X per cycle.

The BCWS for the total planning package is the cost per cycle multiplied by the number of cycles: 3 * $2X = $6X.

In F17, both members of staff are assigned to six-month epic derived from P. The BCWS of the epic is $2X. The remaining value in the planning package is $4X.

At the end of F17, the epic is completed. The BCWP and ACWP are both $2X. The work is on cost and on schedule: there is no variance.

In S18, A is reassigned and is unable to work on a new epic derived from P. B continues the work alone, completing an epic worth $X by the end of the cycle. The BCWP and ACWP are now both $3X; there is no cost variance. However, the BCWS is $4X: compared to the original schedule for the planning package, there is a schedule variance of -$X. There is a total of $3K left in the planning package.

In F18, C joins the project. C only costs $0.5X per cycle, but is a fast worker: she can complete in one cycle work that would take A or B two cycles.

B and C work together through F18. The ACWP for the cycle is $1.5X; the BCWP is $3X. The ACWP to date $4.5X. The BCWP and BCWS are both $6X. At this point, the project is complete: there is no schedule variance, and a cost variance of +$1.5X.

Epic-Based Long Term Plans¶

As per Short Term Planning, the epic is the standard level of granularity for planning work over the relatively short term (periods of several months). However, epics may also be valuable for longer-term, fine-grained planning. When a detailed description of work for a given planning package is known, it can and should be described in JIRA through a series of epics assigned to the appropriate cycles. As long as they have not been scheduled for the current cycle, these epics can be freely created and changed at any time, without any sort of approval process. Of course, for this process to be practically useful, these epics should fit within the scope and budget of the relevant planning package.

Fine grained planning of this sort can be usefiul for “bottom-up” analysis of the work to be performed and validation of the resources needed to implement a particular planning package. Thinking through the plan in this way can help in building up a detailed plan in a flexible, agile way, while also ensuring that scope, cost and schedule are carefully controlled.

Defining The Plan¶

Revising the Plan¶

During the cycle, it is possible that changing circumstances will cause reality not to exactly match with the plan. This will ultimately cause a variance, which should be avoided and which—if it becomes significant enough—will require a narrative.

After the plan for the cycle has been entered into JIRA, it is under change control: it can only be altered through a LCR approved by the CCB. In order to reschedule (or remove entirely from the cycle) an epic which has not yet started, the technical manager should work with the Project Controls Specialist to prepare and submit an appropriate LCR to the monthly CCB meeting.

Note that it is not possible to alter history by means of an LCR. That is, if the scheduled start date of an epic is already in the past, it is not possible to move it into the future using a change request. In this case, there is no option but to carry the variance related to the late start of the epic into the future, to describe that with narratives where necessary, and to attempt to address the variance as soon as is possible.

Based on the above, it is clear that technical managers should closely track performance relative to the plan throughout the cycle, and proactively file change requests to avoid running variances wherever possible.

Closing the Cycle¶

Assuming everything has gone to plan, by the end of a cycle all deliverables should be verified and the corresponding epics should be marked as “done”. When an epic is marked as done, it is equivalent to having delivered the required functionality. The total cost of that functionality—the BCWS, calculated as per Mapping SPs to BCWS—is now claimed as value earned.

Epics which are in progress at the end of the cycle cannot be closed until they have been completed. These epics will spill over into the subsequent cycle. It is not appropriate to close an in-progress epic with a concrete deliverable until that deliverable has been achieved: instead, a variance will be shown until the epic can be closed. Obviously, this will impact the labor available for other activities in the next cycle. (This does not apply to bucket epics, which are, by their nature, timeboxed within the cycle).

Similar logic applies to epics which have not been started: if the planned start date is in the past, they can no longer be rescheduled by means of an LCR. They must be completed at the earliest possible opportunity; you will show a variance until this has been done.

Defining Stories¶

Epics have already been defined as part of the cycle plan. However, the epic is not at an appropriate level for scheduling day-to-day work. Rather, each epic is broken down into a series of self-contained “stories”. A story describes a planned activity worth between a small fraction of a SP and several SPs (more than about 10 is likely an indication that the story has not been sufficiently refined). It must be possible to schedule a story within a single sprint, so no story should ever be allocated more than 26 SPs.

The process for breaking epics down into stories is not mandated. In some circumstances, it may be appropriate for the technical manager to provide a breakdown; in others, they may request input from the developer who is actually going to be doing the work, or even hold a brainstorming session involving the wider team. This is a management decision.

It is not required to break all epics down into stories before the cycle begins: it may be more appropriate to first schedule a few exploratory stories and use them to inform the development of the rest of the epic. However, it is required that all stories which will be worked in an upcoming sprint are defined before the sprint starts.

Note that there is no relationship enforced between the SP total estimated for the epic and the sum of the SPs of its constituent stories. It is therefore possible to over- or under-load an epic. This will have obvious ramifications for the schedule. See Earning Value for its impact on earned value.

Sprinting¶

Each team organizes its work around periods of work called sprints. A sprint comprises a defined collection of stories which will be addressed over the course of the month. These stories are not necessarily (indeed, not generally) all drawn from the same epic: rather, while epics divide the cycle along logical grounds, sprints divide it along the time axes.

Broadly, executing a sprint falls into three stages:

1. Preparation.

   The team assigns the work that will be addressed during the sprint by choosing from the pre-defined stories. Each team member should be assigned a plausible amount of work, based on the per-story SP estimates and the likely working rate of the developer (see Estimating Effort).

   The process by which work is assigned to team members is a local management decision: the orthodox approach is to call a team-wide meeting and discuss it, but other approaches are possible (one-to-one interactions between developers and technical manager, managerial fiat, etc).

   Do not overload developers. Take vacations and holidays into account. The sprint should describe a plausible amount of work for the time available.

2. Execution.

   Daily management during the sprint is a local decision. Suggested best practice includes holding regular “standup” meetings, at which developers discuss their current activities and try to resolve “blockers” which are preventing them from making progress.

   Stories should be executed following the instructions in the Developer Guide as regards workflow, coding standards, review requirements, and so on. It is important to ensure that completed stories are marked as “done”: experience suggests that this can easily be forgotten as developers rush on to the next challenge, but it is required to enable us to properly track earned value.

   Avoid adding more stories to a sprint in progress unless it is unavoidable (for example, the story describes a critical bug that must be addressed before proceeding). A sprint should always stay current and should be up-to-date with reality; if necessary, already scheduled stories may be pushed out of a sprint as soon as it is obvious it is unrealistic to expect them to be completed.

3. Review.

   At the end of the sprint, step back and consider what has been achieved. What worked well? What did not? How can these problems be avoided for next time? Was your estimate of the amount of work that could be finished in the sprint accurate? If not, how can it be improved in future? Refer to the burn-down chart for the sprint, and, if it diverged from the ideal, understand why.

   Again, the form the review takes is a local management decision: it may involve all team members, or just a few.

We use JIRA‘s Agile capabilities to manage our sprints. Each technical manager is responsible for defining and maintaining their own agile board. The board may be configured for either Scrum or Kanban style work as appropriate: the former is suitable for planned development activities (e.g. Science Pipelines development); the latter for servicing user requests (e.g. providing developer support).

Handling Bugs & Emergent Work¶

Earning Value¶

The basic procedure for earning value during the cycle is akin to that discussed earlier for long term planning.

In short, as we have seen, the BCWS for a particular epic is defined by its estimated (i.e. attached to the epic before work commences) SP total and its staff assignment. When an epic is marked as complete, this is the value that is earned.

The BCWP for an epic is calculated based on the fractional completeness of an epic. That is, if an epic has a total SP count of X, and the total of stories marked as complete within it is Y, then BCWP = BCWS * Y / X.

Be aware that stories that marked as “invalid” or “won’t fix” in JIRA are not included in this calculation: they earn no value.

As we have seen, it is not required that the total SPs of all the stories contained within an epic (the “planned SPs”) is equal to the total SP estimate of the epic itself (“estimated SPs”). Further, it is permitted to add stories to (or, indeed, remove stories from) the epic during the cycle. In these cases, we hold to two basic tenets:

1. No epic can ever be more than 100% complete;
2. Completeness cannot decrease. That is, if an epic has been registered as 90% complete, adding more stories cannot make it less complete than before.

In order to meet these criteria, the relative weights of stories will be automatically adjusted on ingest to the PMCS. The detailed algorithm by which this adjustment is made is not publicly documented.

JIRA Maintenance¶

At any time, new tickets may be added to JIRA by team members. Please remind your team of the best practice in this respect (RFC-147). It is the responsibility of technical managers to ensure that new tickets are handled appropriately, updating the schedule to include them where necessary. It is required that the Team field be set to the appropriate team (RFC-145). Please regularly monitor JIRA for incomplete tickets and update them appropriately. Where tickets describe bugs or other urgent emergent work which cannot be deferred, refer to Handling Bugs & Emergent Work.

Coordination Standup¶

The technical managers meet with the Project Manager and interested others (it is not a closed meeting) twice every week. This is a forum to discuss general project management issues, but, in particular, to resolve issues which cut across team boundaries and are relevant for the ongoing sprint.

Meetings take place using Google Hangouts at a pre-arranged URL. Meetings take place at 11:00 (11 a.m.) Project (Pacific) Time on Tuesdays and Fridays.

Monthly Progress Narratives¶

Every calendar month, each technical manager is required to support the Project Manager with a report on the activities of their group. This report should be generally submitted no later than tenth of the month (refer to the Standard Reporting Cycle), but this may be moved earlier on occasion. You are encouraged to submit your report as early in the month as possible.

Submit your report by editing the template for the appropriate month on Google Docs. You need to fill in all the sections with your name attached; when complete, remove your name. Provide a brief (one or two sentences) high level summary, a per-WBS breakdown of work over the month being reported on and plans for the upcoming month, as well as describing any recruitment activities (positions opened, interviews conducted, appointments made, etc). Refer to previous reports for examples of the style used (but note that they are not not always consistent).