What is a Value Stream?
A value stream is like a roadmap showing all the steps needed to create a unit of value (i.e. a feature) from the idea to the customer's hands. It show the time spent on each step, the delay between steps and is pretty useful to identify wasteful activities and fin ways to make the process smoother and faster.
Value Stream management focuses on two thing: how quickly a customer receives its requested feature and whether the customer realizes the value from those changes.
The concept of Value Stream is central to Lean Thinking. Value Stream already exist in companies, even if they aren't labeled as such.
Important: all cycle time are measured in calendar days (including weekends), and not time spent working. When we think in cycle time, we think in a customer perspective. We want to answer questions for customers such as when will I receive X? Learn more why we measure in calendar days.
How does Axify create a Value Stream?
Axify connects your development tools (i.e. Jira, Azure DevOps, Jenkins, etc) to measure your lead time. We measure different cycle times based on three levels: deliverable lead time (i.e. how long to complete a feature), issue cycle time (i.e. how long to complete a user story) and lead time for changes (i.e. how long to bring a changes to production).
We believe these 3 levels impact each other and we allow to inspect your cycle time at these three levels. For example, making smaller Pull Requests will tend to reduce the time it takes to complete a user story, and smaller user stories will tend to reduce the time it takes to complete a feature.
What is a Deliverable?
In Axify, we use the term Deliverables to represent a unit of value that is relevant to the business and stakeholders. Typically it represents an epic or a feature. It is something larger that a simple user story.
We use the term Deliverable because there is no standard in the industry. No two companies work the same, some use epics while others use features, some use both. For some an epic is larger than a feature, but for others it's the opposite. We wanted a term that is agnostic of the agile community or a framework.
How Deliverables lead time works?
When you inspect the Deliverables tab, you will see four phases. These four phases are normalized, meaning they are not dynamic from your board, and is a unique model that is used across the organization. It is shown as below.
A Deliverable is something you can configure in the Project Settings. In Jira, it is an epic. In Azure DevOps, you can choose if you want to track epics or features.
Then, the first milestone you see is Deliverable is created. We capture the moment you create a Deliverable in your issue tracker and the timer starts.
The second milestone is First issue has entered development board. The moment Axify detects that a child issue (i.e. a user story) enter the selected development board in the project in a recognized status (i.e. To Do), the Deliverable enters this phase. The idea is to represent that the Deliverable has been shipped to the Development team so it can start refining and working on it.
The third milestone is In Development. The Deliverable enters that phase when its first child issue is In Progress for the first time.
The fourth milestone is Post Development. The Deliverable enters that phase when the last child issue is considered done.
We finally consider a Deliverable done when you mark it as done.
Pro tip: you always can inspect how we calculate the deliverable lead time. We provide a table in the page with the raw data for each Deliverable, it is pretty useful to see what was the lead time for a specific Deliverable and why it happened.
What is Issues cycle time?
The issue cycle time represents how long does it take to complete an issue. An issue is the first-level item in your Development board, so typically a user story, a bug, a task, etc. We use the term issue to stay agnostic from your integration provider, for example Jira and Azure DevOps does not share the same terms.
In Axify, you can see you issues cycle time by click on the Issues cycle time tab in the Value Stream page (shown as below).
The columns in blue represent what phases means In Development for the team. The columns in grey represent what phases happens before the development. You can model your workflow in the Project settings, we adapt to many ways of working.
The idea behind Pre Development is to reflect work that hasn't started its delivery, that is still being refined. Commonly known as the upstream work. Sometimes a team will have a "Ready to sprint" column, waiting to be pulled, and then the item is being worked on. The issue cycle time only consider items In Development in its calculation to better reflect the context of the team.
The phases in the Issues cycle tab are dynamic, meaning you see the same columns in your board in your integration provider and in Axify. We don't normalize these phases, it allows you to understand which phases bottleneck more and where the time is being spent.
Pro tip: you always can inspect how we calculate the issues cycle time. We provide a table in the page with the raw data for each issue, it is pretty useful to see what was the cycle time for a specific issue and why it happened.
What is lead time for changes?
Lead time for changes is the time between your code committed to your code successfully running in production. It is one of the four key metrics in the DORA research.
In Axify, we broken the lead time for changes into four sub phases: coding, pickup, review and deployment.
The Coding phase reflects the time from the first commit to the moment the pull request is opened.
The Pickup phase is the time from where the pull request is opened to the first interaction (e.g., comment, reaction, thumbs up). This phase is important as it may reflect a bottleneck in your flow like idle pull requests or where the pull requests get stuck.
The Review phase represents the time from the first interaction (e.g., comment, reaction, thumbs up) to when the pull request is merged. It reflects the time to review the pull request and the back-and-forth between team members before it is merged.
The Deploy phase represents the time from the pull request being merged to it being deployed.
Pro tip: when your deployment is not set up yet, the VSM fallback to your pull requests cycle time. Pull Requests cycle time is a subset of the lead time for changes, simply missing the deployment component. It allows to still have a partial view of your technical efficiency.
Where should I focus first?
We tend to look at Deliverables first. How long does it take to complete a Deliverable. Rule of thumbs, we suggest less than a month to deliver a Deliverable. Break down epics/features, deliver sooner but more frequently.
Then we look at Issues cycle time. How many phases do you have? Identify phases where you have a handoff or waiting for approvals. These phases generally takes more time. Look for ways to remove them or reduce their need. For example, if you have a Waiting for QA phase, we would probably recommend to shift left on testing initiative and a fix-forward approach (inspired by continuous delivery).
We also look at Lead time for changes. Are Pull Request too big or coding time is high? Are pull requests idle (high pickup time or review time)? Is deploying to production high because you need to deploy in multiple environments? Look for ways to improve automation.
In general, the quickest win is in lead time for changes. Optimizing technical efficiency will impact the time to complete an issue (i.e. user story), followed by epics too.