A recent report reveals that 71% of companies are adopting Agile, whilst 60% of companies claim to have experienced a growth in profits after adopting an Agile approach.

At Appsbroker, we help organisations address specific needs and achieve a high level of business agility with a trusted approach to project planning and delivery so everyone can feel the benefits, including customers, consumers and teams – And optimising your Discovery Sprint is a great way to kick things off and set the right tone for future work.

Here are the key points to consider from Marina Bellenzier, Agile Coach at Appsbroker, and her colleagues.

What are Discovery Sprints and Why do I Need Them?

When a project is starting, there is a lot of uncertainty. Some of this is due to unknown information, but gaps between stakeholders’ points of view, a lot of assumptions that aren’t verified and a lack of a shared vision may also contribute to uncertainty. All these issues can be counterproductive to the project if they are not identified in time.

Discovery Sprint is a useful method to build a common understanding of the current state and create paths toward solutions. In Appsbroker, we use this method in a majority of our projects and we’ve found it a really helpful tool in speeding up our teams.  

What happens during a Discovery Sprint?

Most of the projects start with a fixed Discovery period which is named Sprint 0. The duration of Sprint 0 can vary from project to project, but usually, it’s from 1 week to 3 weeks.

Generally, it’s recommended that the group consists of all people involved in the project, including internal or external stakeholders, the engineering team, the project manager, the scrum master, the product owner, the business analyst and other decision-makers. 

During a Discovery Sprint, the team interviews stakeholders to deeply understand their needs and identify risks and opportunities. Bear in mind this is not a time window to solve problems. 

How to make your next Discovery Sprint awesome

Clarifying the purpose of this initiative plays a key role in making people feel engaged and collaborative. 

To help you get started, here is a list of essential outputs that we consider at Appsbroker to make every Discovery Sprint awesome.

  • Empathy Maps

We believe that creating an effective solution requires understanding both the problem and the person experiencing it. Creating empathy maps helps the team consider things from the customer’s perspective and focus on their goals and challenges.

  • Vision Statement and project success criteria

Defining a vision statement and project success criteria supports us in setting realistic expectations for optimal results. We insist on agreeing on this with our customers and making it visible throughout the project. In addition, it allows us to build a trusting relationship with the customers and promote transparency.

  • High-Level Roadmap 

A Roadmap is a strategic communication tool for project management. Bringing everyone together in the Discovery Sprint, we build a crystal-clear roadmap that clearly communicates deliverables and the expectations for where the project is going and why. This is usually a live document that can be changed by customer prioritization. We use this roadmap on an Epic level to guide the team on iteration planning and make our progress visible. 

  • Current State and Future State diagram

When we understand the current state, we can identify challenges that need to be solved: confusion, inconvenience, inefficiency, and relevance. This is essential for empowering all people involved across all functions. Operating with clarity on the customer’s current situation (compared to their ideal situation) allows us to determine where to focus, why, and how to shift into addressing the challenge or opportunity. Simply put, ‘as-is’ maps where the processes are and ‘to-be’ maps where you want them to end up.

  • High-Level Design 

We encourage the team to take high-level thinking about the solution by creating High-Level Design and presenting the system structure as the application/database architecture. It’s important to start some discussions around the best solution and feasibility. Sometimes, we undertake further research or invite specialists to help us make the right decision. The added benefit here is the creation of more time to invalidate any idea and start again.

  • Initial Backlog

We use the Scrum Framework to run our projects and iterate throughout the services we provide. With a High-Level plan, we can start refining the first project stories. Reducing uncertainties will give us more autonomy and safety to build the best solution for our customers. Using the right tool to manage our project, we create our Epics and stories for a maximum of 2 sprints. In this part, it’s considered good practice not to plan too far ahead.  

  • Estimation

The goal is to provide a rough estimate for the first plan. Even if we have a “beautiful” Roadmap, in the end, the customer always wants to know when the project will be complete. We can use ROM (Rough Order Magnitude) estimates to provide a project owner with a high-level plan for regular reporting to stakeholders. This is very important for promoting transparency and aligning expectations with our customers.

  • Team Charter

A key factor in any successful project is how the team is formed. The team members must understand why they exist, where they fit, and how they’ll accomplish their objectives. With a Team Charter, we build an agreement on how our unique team members will best work together. Also, we define some ways of working based on Agile principles and document DoR (Definition of Ready) and DoD (Definition of Done) for the backlog items.

Not all of these outcomes are required; it depends on the context, customer or service type. We always adapt to better fit both the purpose and our client’s needs. However, all of these practices will be used in the Delivery phase, in order to guide the team towards the right priorities and the right solutions.

How do I keep my Discovery Sprint on track?

To build those outcomes in a logical sequence, we prepare an Agenda. The agenda ensures that the workshop stays focused and that everyone knows what is happening and what will happen next. Without the agenda, the Discovery Sprint can rapidly become chaotic, and the main goals may not be completed.

This is an example of a Typical Discovery Sprint Agenda:

Final Thoughts

In our last Discovery Sprint, we engaged more than 15 stakeholders,  ran over 20 workshops and generated more than 10 artefacts during a 3-week period. It helped lay the foundations for the subsequent sprints and ensured the project was on a secure footing through: 

  • Establishing a shared vision and ensuring all stakeholders were on the same page
  • Having empathy with our users, understanding their pain points,  goals and critical success factors
  • Abstracting the problem to its essential components
  • Clarifying the As-is and agreeing on the to-be business process
  • Eliciting the essential and high-level requirements    
  • Creating the initial epics and the emerging backlog
  • Diving deeply into the technical problems
  • Providing the inputs to produce both the High-Level Design and initial estimates

Building a great house requires a solid foundation. A Discovery Sprint helps to clarify the project vision and minimise risks. It empowers the team to implement the project just as it was intended.

What has your experience with Discovery Sprints been like? Do you have any tips or questions? Let us know in the comments.

About Appsbroker

Appsbroker is one of the largest Google Cloud-only Managed Service Providers in EMEA, delivering extraordinary transformations using agile methods and best practices with GCP and Workspace.