A common challenge, however, is converting relative sizes into specific time and cost estimates—especially when using story points or t-shirt sizes to gauge the scope of work for new projects. This issue becomes even more pronounced when forming a new delivery team whose members have not yet worked together. Without reliable historical performance data, the team cannot rely on recent velocity or previous relative sizing. In these cases, the team must reach a consensus on the baseline stories for each relative size. They then review the entire product backlog, comparing each story to the established baseline to assign appropriate story point estimates. The aggregated total of these story points represents the size of the build and test phases of the project.

What happens next?

‍

Identify Possible Parallel Streams of Work and Optimal Team Size

A realistic delivery plan depends on understanding how many parallel workstreams can be established, when they can commence, and how to unlock them as soon as possible. To achieve this during our inception workshop and delivery planning sessions at Fabric, we follow these steps:

‍

• Map Dependencies: We analyze dependencies between features and stories to determine where one area relies on another. This helps us organize parallel workstreams so that interdependent tasks are either scheduled sequentially or assigned to teams that work closely together.
• Unlock Infrastructure Tasks: We identify and prioritize infrastructure tasks—such as setting up CI/CD pipelines, configuring cloud environments, setting up databases, and implementing security measures—to ensure that these foundational elements are in place, enabling the rest of the build workstreams.
• Identify Shared Modules or Services: We pinpoint modules or services required to initiate work on specific features or stories. For example, an authentication module can be built as a reusable service that various teams later integrate, reducing redundant work and allowing for more parallel development.
• Align Workstreams with Team Skills: We match the defined workstreams with the team’s skills and availability. Each parallel stream is planned based on team capacity, ensuring that every team member is assigned to the stream that best leverages their expertise.

By the end of this analysis, we agree on an assumed team size and composition—such as 2 onshore senior engineers and 3 offshore software engineers—to ensure optimal resource allocation and effective delivery.Define Your Team's Raw VelocityDuring the project inception workshop, Fabric teams engage in a “velocity exercise” to establish their raw velocity. In this exercise, the team works with storypoint estimates hidden and fills a few hypothetical sprints up to capacity. The objective is to stop adding stories when a sprint “feels full.” Once the exercise is complete, the workshop facilitator reveals the estimates and calculates an average total across the sprints. This average represents the team's raw velocity—the number of story points a team of a given size can deliver per sprint under ideal conditions.The team may repeat the exercise several times until they are confident in their raw velocity estimate. For example, after multiple rounds, the team might agree on a raw velocity of 30 story points under ideal conditions.

‍

‍

‍Consider Average Utilisation Factor

‍The raw velocity rarely reflects a team’s actual productivity. Several factors, anticipated during the inception workshop and delivery planning, can affect the team's real performance once work begins. For example, team capacity can vary due to holidays, vacations, training sessions, illnesses, or part-time availability. Additionally, development capacity might be reduced by production issues that require immediate attention.Team turnover is another critical factor. New members need time to reach full productivity, and simply adding more people doesn’t necessarily speed up progress.At Fabric, we typically account for a maximum utilisation of around 80-90%. For instance, if the raw velocity is 30 story points per sprint, we expect it to effectively drop to about 27 story points per sprint due to these factors. Consequently, a project with a total scope of 162 story points would take roughly 6 sprints to complete the build and test phase.

‍

‍Add Time and Effort for Delivery Inception and Sprint Zero Activities

‍In addition to the build phase—which factors in the build and test effort based on raw team velocity, total estimated story points, and the utilisation factor—we must also account for early project activities. These activities include the project inception workshop and sprint zero activities.

Project Inception Workshop:This workshop, typically lasting 1–3 weeks, requires dedicated resources including a delivery lead, a technical consultant, and an experienced designer. The workshop sets the foundation for the project by aligning the team on goals, expectations, and initial planning.

Sprint Zero Activities:After the inception workshop, sprint zero activities are essential to prepare the project for full-scale development. These activities include:

• Securing access for all team members
• Setting up code repositories and cloud accounts
• Configuring local development environments
• Establishing repositories for requirements and UX mockups
• Implementing delivery tracking tools

Incorporating these activities provides a realistic timeline for ramping up to full team velocity and offers a more accurate projection of the associated costs.

‍

‍Add Time and Effort for Supporting Production Readiness Activities

‍After completing the build phase, it’s important to allocate time for production readiness activities. These activities include end-to-end testing, user acceptance testing, security reviews, load testing, and other governance tasks required to launch new software into production. The duration and resource requirements for this phase vary depending on the scope and complexity of the software release.At Fabric, we collaboratively determine a realistic timeframe for these activities by considering historical timelines from similar projects. Typically, this phase lasts between 2 to 10 weeks. Including these efforts in the overall plan ensures that the delivery timeline and go-live dates accurately reflect all necessary steps for a successful launch.

‍

‍List Delivery Assumptions, External Dependencies, and Risks

‍Every delivery plan is built on a set of assumptions that need to be clearly documented and mutually accepted by the project team. It’s important to acknowledge that any changes to these assumptions may result in delays or unexpected modifications to the plan, which we will manage accordingly. Typical assumptions include:

• Raw Team Velocity: The estimated pace at which the team can complete work.
• Shutdown Periods: Scheduled public holidays, breaks, and other periods when the team is not available.
• Utilisation Factor: The realistic percentage of the raw velocity that can be achieved.
• Team Size: The number and mix of team members available.
• Parallel Workstreams: The availability and feasibility of running multiple workstreams concurrently.
• External Dependencies: Any third-party inputs or integrations that may impact progress.
• Testing and Sign-off Timelines: Maximum time allocated for UAT/SIT completion and client sign-off.

The baseline delivery plan—created collaboratively during the project’s inception phase—provides an accurate prediction of the project timeline and the factors critical to its calculation. As execution begins, changes to the scope, external dependencies, resource allocation, or parallel workstreams are inevitable. However, a delivery plan based on relative sizing can be easily recalculated and adapted to these changes. It also enables us to quickly simulate different delivery scenarios, such as adding new team members, adjusting scope, reprioritising features, or modifying the plan to accommodate fluctuations in team velocity.‍

‍

In summary, a robust delivery plan hinges on clear assumptions, a realistic understanding of team capacity, and the flexibility to adapt as conditions change. By integrating techniques such as story points estimation, identifying parallel workstreams, accounting for production readiness, and acknowledging key dependencies and risks, Fabric ensures that every project is set up for success from inception through to go-live. This dynamic planning approach not only provides an accurate timeline but also empowers teams to swiftly respond to challenges and adjust strategies as needed.