SNAP is an enterprise agile framework based on team collaboration, and Lean Management.
Among the founders of SNAP we've SAFe certified practitioners, and agile coaches familiar with other frameworks.

We believe SNAP propose a simpler, integrated approach to enterprise agility, by combining the best solutions currently available in the market.
Our main focus is to help the enterprise to improve business agility by using a framework that is flexible and simple to implement.

Many organizations are deciding to improve their business agility by adopting Scrum. Scrum is easy to learn and effective, in many situations.
However, long-term agility comes from a cultural change, and as with any type of organizational transformation, the result depends on several factors. One thing is common to all: the wrong process produces the wrong results. 

Even when fully mastered, as the team grows, we need to scale up Scrum into something capable to manage multiple layers of the enterprise.
To facilitate that, the agile coach need to apply an holistic approach, supporting strategic objectives, vision, and portfolio delivery.

SNAP advocate Lean Management, and is based on the following core values:

  • Agile leadership
  • Sustainable flow of value
  • Continuous improvement

Continuous improvement is key to support a change in mindset.
Continuous learning, and reducing waste are part of this process of continuous improvement.
For example, Agile leadership needs coaching and continuous learning in order to drive the changes required by the organization, and to stay competitive in the market.

Value streams, the steps and people needed to deliver a continuous flow of value, business objectives, and vision are identified , and propagated in all layers of the organization. Value stream mapping is then performed in order to maximize business value and customer satisfaction. The sustainable flow of value, is the result of a mature business agility. Business agility is the ability to achieve a continuous flow of value by managing change, speed and quality, effectively. To achieve business agility the organization needs to support the holistic transformation, that creates a collaborative environment in all layers of the organization. Servant leadership is key in this process.

Measurable results are tracked by assigning business value to each Feature, and during Sprint review the product increment and its business value, are both tracked.

SNAP suggest a management practice that shift focus from projects to products and solutions. Products and services can be aggregated into larger solutions, and carry the continuous flow of value to the customer. The agile coach needs to understand the challenges, the company's culture, and the expectations, to facilitate the holistic transformation of the organization.

As the agile manifesto states, processes and tools are not as valuable as individual interactions. Regardless of the agile framework we use, building the Team, and supporting the mindset in all layers of the organization, is the first step to achieve business agility.

How it works

SNAP is a framework designed for the enterprise, and deployed in some organizations operating in the FinTech industry. While designing this framework, our goal was to keep it simple. We didn't want a cure that is worse than the disease, so we tried to avoid solutions that were over-complicated, impractical, or too prescriptive clashing with the principle of creativity advocated by Agile.

In SNAP, a project is managed as a product, and budget is allocated to value streams.
The requirements for such product are defined in the Epic and Feature backlogs.
In contrast with a traditional waterfall project where the focus is on Design & Planning, Agile delivery focus on Quality and Speed achieved by creating a constant loop with the customer, which in turn will promote a culture of continuous improvement.

Enterprise Levels

SNAP divide the Enterprise in 3 levels :

  • Domain
  • Group
  • Delivery

A Domain consist of stakeholders that are responsible to shape business vision and business strategy which must align to customer needs. Business objectives at this level are called portfolio epics. Financial investments are managed at this level through Lean Portfolio Management where products, not projects, are funded. The business value measured in Value Points, or VP, is identified at this level through the DVR approach where D is customer desirability, V is business value for the organization, and R is risk related to the work. These terms are all measured as integers from the Fibonacci sequence, and contribute to prioritize work as per the short job first. For example: higher risk items (eg. Features) will reduce VP, whereas higher Desirability an business value will increase it.

A Group consist of stakeholders that manage customer value delivered as Features, which in turn are a breakdown of portfolio epics. This group includes SMEs, senior Managers, Lead Agile coaches, and Delivery managers.

A Delivery level consist of stakeholders that deliver customer value as user stories. This level includes Engineers, SMEs, Product owners, Scrum masters, and Agile coaches.
This level works with traditional Scrum Teams or Squads and Tribes.



SNAP use the followings structure to streamline the delivery:

  • TeamWorks
  • WorkGroups

TeamWorks consist of up to 9 Scrum Teams, for a total of 9x9 = 81 people.
Each TeamWork has its own SMEs. Ideally all teams should run sprints in parallel with each other, so that all sprints start and finish at the same time.
A WorkGroup contain up to 3 related TeamWorks for a total of 81x3 = 243 people.


SNAP consider business, functional, and non functional requirements defined as items with the following hierarchy:

  • An Epic consist of one or more Features
  • A Feature consist of one or more Stories
  • Stories can be related to the user, User Stories, or technical stories, and are the smallest unit of requirement. They include business, functional, and non functional requirements.

SNAP suggest to allocate the capacity of the team so that technical and non technical stories are delivered in parallel during Sprint execution. For example 70% allocated to user stories, and the remaining to technical stories, or exploration stories that support new ideas (spikes).


SNAP suggest the following Events:

  • Kickoff
  • QBR
  • Simulations
  • Planning
  • Discovery
  • T-Review
  • Sessions

Kickoff Meeting

This meeting occur at the beginning of the Agile Transformation. The purpose of this meeting is to share the vision, the strategy, and the expectations of the stakeholders.

  • Vision of the Agile Transformation (what we want to be)
  • Strategy (how to get there)
  • Projects involved and priorities
  • Support required
  • Shared documentation, collaborative tools, dashboards

This meeting is crucial because people from all layers of the organization are expected to start collaborating with each other on a shared set of goals. By knowing Who and What, people will engage in the agile journey from day #1. The kickoff can be as short as 30', and should not exceed 90'.


QBR, or Quarterly Business Review runs every 3 months and define the next PI , or product increment as a set of epic and features that carry a priority value for the business. During this meeting Group and Domain leaders share the vision, achievements of the previous quarter, challenges, and the roadmap of the next quarter.
The PI is achieved through multiple sprints that run in parallel in different Groups and Domains.


Agile simulations are a simple and fun way to start the journey by engaging with different teams. Simulations, or Agile games, involve people playing in person in the same room, or remotely.

Ideally the following Teams play the simulation:

  • Client
  • Steering Committee
  • Service Desk
  • Operations
  • Scrum Teams

Participants doesn't need to have programming skills to complete the simulation.
Ideally the game consist of 2 parts: a situational quiz and a conversation.
This type of game can be used to clarify agile principles, reduce communication barriers, and trigger further discussions.
The Agile simulation engine AGame, is available as SaaS on this website.


This meeting focus on the Feature Backlog, and is facilitated by the Product Manager.
Each participant should contribute actively to this meeting, they should add value by sharing feedback as servant leaders.

T-shirt estimates are used in this meeting since stakeholders usually only have a hi-level view of the Features they want to deliver.

For example: we could have 2 small Products, that can be fitted into one Teamwork of 8 Teams, or 2 TeamWorks of 3+5 Teams.
Having 2 or 1 Teamwork depends on the criteria that we want to apply. For example, we could use the following criteria: co-location, current workload, and constraints of the infrastructure. When there are dependencies, ideally we group Scrum Teams together, to form a TeamWork. This is done to reduce communication barriers between multiple scrum teams.


In this meeting the team discuss what they'd like to include in the next iteration. It's important to make sure all relevant stakeholders attend and contribute actively to the outcome of this meeting.

Teamwork Review

Teamwork Review is similar to the Sprint review, but called at the Teamwork level at the end of the sprint.
All stakeholders should attend this meeting, and the purpose is to demonstrate the product increment delivered by the Teamwork, in a single session. The assumption is that all Sprints in the Teamwork run in parallel; they start and finish at the same time. This time-boxed unit, is called an Iteration, and is equivalent to one Sprint, if all Sprints start and end at the same time.


Sessions are short meetings called at any level, to discuss specific aspects of the product.
Ideally they should focus on one or two aspects, and should not last more than 1 hour.
More sessions can be called if they help to clarify the business objectives of the current iteration.

Budget Session
This session is usually called at Portfolio level to discuss investments, and how program's estimates are evolving.

Support Session
This session focus on the support required to execute the product increment.
For example, a 3rd party vendor is required to attend the daily standup, or to escalate an issue, or to deliver technical trainings to the team.
RAID Session
This session can be called at any level, and focus on Risks, Assumptions, Issues, and Dependencies. At Delivery level, this is equivalent to the Scrum of Scrums.

Retrospective Session
This session can be called at any level, and focus on innovating and improving the collaborative environment. This meeting is like the Scrum retrospective .

Refinement Session
This session helps to consolidate the product and feature backlogs against evolving risks and dependencies. All stakeholders should join and contribute to refine the backlog, and prioritizing it.


SNAP is not prescriptive about metrics, but advocates Dashboards where tangible progress is shared across multiple teams.
Senior stakeholders need to understand what benefits agile delivery was able to deliver, against the initial investment.
Tracking business value, is an important metrics that helps the business to understand their customers, and to continuously improve.

Some people get nervous when you talk about metrics and KPIs because they see them as a threat to their autonomy and safe zone. However, metrics are important for everyone to baseline progress, and to continuously improve, and continuous learning should be provided to improve alignment to agile practices, and reduce resistance.

We may have been on a product where no data of any kind was tracked, and it was hard to tell whether we're on track for release, or getting more efficient as we go along. On the other hand, many of us have been on a projects where stats were used as a weapon, pushing one team against another in a toxic competition, or justifying overtime. So it's no surprise that most teams have a difficult relationship with metrics.

But it doesn't have to be that way.
Tracking and sharing agile metrics can reduce confusion, and will shine a light on the team's progress throughout the development cycle. Finding the right metrics is a collaborative effort that can save Teams from unnecessary pressure. When KPIs are shared in a dashboard, everyone knows the progress, and your team can focus on the actual work, rather than be chased by business owners, and attending long meetings.