In the federal government, budgets require a multi-year planning cycle. Therefore, any effort to reduce the uncertainty of future year program costs leads to better and more defensible budgets for those years. But Agile programs focus on near term workload and activities with only limited future planning cycles identified. Future cycles are only activated as their start date nears. So any model-based cost estimate or predictive analysis for the budget needs to be flexible, responsive and adaptive to the daily dynamics of Agile program planning and execution.
Unison TruePlanning estimates Agile costs using a flexible, scalable approach to normalize program costs over time, to simultaneously recognize and tailor future planning cycles and near-term execution cycles. Based on user entered working velocities and development team skills, an Agile model predicts hours required for program execution tasks (throughput) assigned for completion in specific time cycles (releases and sprints) to deliver defined viable capabilities (work-in-process) leading to a complete system. Unison TruePlanning allows for dynamic expansion of a WBS to apply data from current and past work cycles (sprints; releases) to estimate future planned cycles. Each estimate begins as a single capability story (epic Story) but expands over time to account for individual backlog items and integrated features.
The Unison methodology for Agile makes the following assumptions:
- Agile is a management strategy, not a new language or new method to create software code. System developers still design, code, test, integrate and field software end items.
- Key changes in the TruePlanning displays and metrics include Agile metrics (burndown rates, story point counts, feature counts and details) and reported effort for sprints and releases.
- Not all Agile tasks require programmers to write code. Agile tasks also include integration, data management, test, or other direct activities.
- The “effort” for any task still needs to be sized to predict the hours required to complete the task, based on a narrative story of what the task entails.
- Relative “Story Points” can be used as a common reference term for size, even though the relative effort per Story Point changes from team-to-team, and task-to-task.
- For predictive modeling, Story Points can be calibrated to how software is developed to create a velocity measure, for example:
Historical Story Points per Lines of Code, Functions, or Cases / Historical Hours for Lines of Code, Functions, or Cases = Planned Story Points per Hour
- This velocity is a flexible team-level measure that changes frequently as language, product functionality and project complexity change – even in a single release cycle.
The process starts with the “Grand” Story. Predicting costs begins with understanding the overall epic story describing the capabilities to be delivered, and the high-level planning map for delivery over time (release planning). Each epic story is then parsed into potential lower-level capability stories. These capabilities can then be assigned to future planning increments over time. Each time increment is modeled with a parent-level Agile Assembly model object.
Each capability increment (release) also includes an overall assessment of the tasks required for completion of the capability, and available teams to do the work. The team description includes their individual characteristics and the total characteristics of all teams as a group (number of FTEs, language skills, organizational productivity, sustainable velocity).
The initial estimate for a single capability (the grand epic story) employs the overall size of the analogy (sum of expected tasks), and the total team characteristics (velocity, team size and average skills) of all teams as if they were a single team. This single capability “task” is executed by the model to arrive at a grand, overall estimate of hours, number of releases, and number of lower-level increments (e.g., sprints) required to complete the overall project.
As releases are opened, more detail is added down to the individual backlog item level (granularity). Working with the development team, estimators create specific SW Features (deliverable SW that meets the needs of the customer) to be completed within a release window. These features add detail to the initial single epic by parsing the capabilities into Features (also an Agile Assembly Object) consisting of one or more tasks, improvements, or enhancements to perform.
Each task, improvement or enhancement within a feature is a backlog item, and is modeled as an Agile SW model object that includes:
- An overall assessment of the size of the task in Story Points; usually as an analogy to a similar completed capability.
- A calibrated Team velocity unique to each task, even for the same team, e.g., Story Points per Hour normalized to the primary SW development measure: LOC, Function Points, T-shirt sized Functions, etc.
- Other characteristics of the task (functional complexity, operating specification, increment length)
- Other activities (integration, test, certification) which are pre-defined in the model
- Bug fixes are always accomplished with each task based on an adjustable defect rate.
The Overall Objective of the estimate is to complete each SW object (Backlog Item) and each Feature (1 or more integrated Backlog items) within the Release time specified in each Feature object.
The resulting Direct Cost equals the Sum of the granular SW Objects and Features:
The Sum of all SW Tasks + Feature Integration = the Feature Cost + the Sum of all Features = A Capability Cost + the Sum of all Capabilities = the Overall Program Direct Cost
Unison TruePlanning can be a key tool for planning and executing an Agile program approach. TruePlanning allows a cost estimator working closely with an Agile team to create and manage estimates as flexible as the team schedule, which capture the dynamics of team velocity and the identified backlog. Results include effort hours, costs and quality metrics scaled to sprints and releases. The drag-and-drop ability to create model expansions quickly allows estimators to keep up with the daily changes to a team schedule.