Many larger size software development project or program consists of multiple teams and have scrum-of-scrums team. These teams have different velocity and capacity even though their release cadence are synchronized well. Often there is challenge in assessing the overall project or program level release predictability by aggregating the individual teams’ metrics for further planning. These measures provide holistic view to understand the project or program performance, project direction, predictability to features completion.

Agile Scrum teams uses Relative Size Estimation to estimate and plan their work in various iterations. Usually team does sprint planning by calculating team’s capacity for the given iteration and sizes the backlog items using relative sizing (mostly planning poker based estimation) methods. Both Capacity Planning and Relative Sizing methods can be combined to arrive at a common method to standardize the estimation technique which can be used across the teams working on the same projects on different features.

Why Team Level Velocity can not scaled as is?

Agile gurus advocate no two teams’ velocity should be compared as each team has different member count, skill composition, level of maturity, feature complexity, and potential goal to accomplish. But at the whole project or program level, a combined metrics is needed to determine the overall performance, quality and time-lines. There are following potential problems in aggregating the team level measures:

Sizing are not based on same unit Story-point- most of the time each team will have different basis for unit Story-point due to different level of teams’ competency and the user story considered to determine the referenced unit Story-point.

Different skills composition of teams – depending on the team’s setup, whether based on Features or Component; members have different level of experience, knowledge, skills and maturity.

Different complexity of features or components– not all features and components in a given project or portfolio have the same level for of complexity, some could be fairly easy while others could be comparatively complex in nature.

Potential Resolution:

By Blending the Capacity Planning and Relative Sizing methods, we can obtain the Program Level Velocity.

1. Determine team’s available capacity for the iteration:

For each iteration planning team should determine their capacity for the iteration. For every full-time developer and tester, team considers 80% of their availability and other 20% are kept reserved for ceremonies and other overheads. Considering two weeks of sprints, each team member’s available capacity is considered to be eight story points, adjusting the part-timers as per their availability and also subtracting one point for every vacation day and holidays. Based on team size, aggregating all members of available capacity, team capacity is calculated.

Product owners and Scrum Master are not considered in this capacity. But if Scrum Master is technically contributing to sprint goal and owns some users stories then his capacity should be considered as per availability.

Then team relatively estimates user stories and selects number of stories to sprint backlog as per their available capacity. The total story-points of user-stories selected is kept lesser than the team’s available capacity.

2. Determine the Reference Unit Story Point of work:

All teams should base the unit Story-point by finding a simpler and commonly agreed user-story which can be completed in one working day. The selected user-story ideally should take half-day to code and half-day to test and validate.

Alternatively, instead of having a single unit story point for all teams, individual teams can determine their reference unit at team level. Calculating unit story point at team level helps to neutralize cross-team level factors and diversities.

Either way, this reference unit story point of work is used to relatively estimate all other user stories in iterations.

3. Structure team appropriately:

First thing first- setup up various cross-functional team within project or portfolio neutralizing the potentially diversity and competence to whatever extent possible. There is nothing much can be done in this regard, except re-balancing it time and again by taking appropriate actions.

Subsequently, while allocating the features or components, try balancing the loads on different teams equally to the possible extent. Feature based teams arrangement have greater benefits, scalability and flexibility in comparison to Components based structure.

Example: No. of team members = 7, sprint length = 2 weeks; Team composition = 1 Product Owner, 1 Scrum Master (with no contribution to development). Assuming no leaves or holidays, the Available Capacity of Sprint = 5 * 8 = 40 Story Points. Hence only user-stories totaling to 40 Story Points should be selected in sprint by the team

4. Aggregate to obtain Planned & Actual Velocity: