# How Long Does A Transformation Take?
How long is a piece of string?
Every company, team, and business process is different, so every transformation is different. The only way to estimate how long a transformation takes is to do as we would with any other problem within an agile environment: brainstorm, collaborate, create a backlog of items, define success, and finally, create a road map.
To really understand how long something takes, you need a **roadmap**—even if it's to recognise when you're **off track**. Without it, you’re flying blind, and it becomes impossible to gauge progress or know whether you'll hit your targets.
A roadmap gives you that **big-picture view**, so even if things don’t go exactly as planned, you'll know **early on** that you won’t make it on time, giving you a chance to course-correct and adjust along the way.
To quickly arrive at a working solution, we've decided to focus on the following key **benefits**:
1. **Increased Agile Maturity**—This is about using Scrum better as we transition. We’ll measure this by tracking how many iterations deliver working, tested software that meets the Definition of Done (DoD), how well **business value** drives product backlog prioritisation, and the extent to which teams are self-organising and continuously improving.
2. **Shortened Development Cycles**—This focuses on shortening the **concept-to-cash** timeline. We’ll measure this by the time it takes to turn an idea into a solution and monitor how this timeline shortens due to the Agile transformation.
3. **Increased Business Value**—This benefit examines the **business value** teams deliver during iterations. We’ll track this by measuring the value output of each iteration and the extent to which it increases through the Agile transformation, using **value points** defined by the Product Owner.
4. **Increased Delivery Reliability**—How reliably teams deliver on their estimates. We’ll measure this by comparing the **forecasted output** (stories or story points) with the delivered output. As teams become more reliable, promises to customers regarding future deliveries will be better kept.
5. **End-User/Customer Happiness**—How satisfied end-users and customers are with the delivered results. We’ll measure this monthly using a **happiness metric** to ensure that customer satisfaction improves, focusing on delivering just enough software—less is more in this case.
6. **Employee Happiness**—This benefit relates to employees' energy and engagement in their work. Happier employees lead to higher retention, easier recruitment, and greater productivity. We’ll measure this using a monthly happiness metric (or at the end of each retrospective). As an alternative, we could track **retention numbers**, though these tend to show slower effects since dissatisfaction builds over time before employees leave.
7. **Increased Velocity (use sparingly)**—How much output a team delivers at a **fixed cost**. While velocity may increase during Agile transformation, it’s important to remember that the real focus is on delivering more **value** driven by the Product Backlog, not just by increasing velocity. We’ll measure the **cost per story point** delivered, allowing us to assess the Agile transition’s benefit by the amount of work getting done at the same cost. By tracking the **value delivered per story point**, we can continuously monitor the **return on investment**.
By focusing on these metrics, we can ensure that the Agile transformation drives real, measurable improvements across the board.
References From
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.7ft10.com/flow-system/agility-and-transformations/intro-to-transformation/how-long-does-a-transformation-take.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.