How to Use Discovery Sprints to Create Great Software Products
By Ecil Teodoro November 6, 2018 10 mins read
In the context of agile software development, Discovery Sprints serve two main purposes: to define what product is being built and to identify an initial set of requirements.
Why use Discovery Sprints? To answer this question I look back at a time when I was learning the standard Systems Analysis techniques. This was back in the late 80’s, when the quintessential computer related job was a Systems Analyst.
After taking several courses towards becoming a systems analyst, I felt ill-prepared to apply for such a job. It wasn’t until after some programming, consulting and leading positions, that I finally felt like I could accomplish these duties successfully. Yet, every time I engaged in a project I felt like there was something crucial missing from the process. These techniques were uncomfortably formal and had a systemic mindset that furthered me from supporting business goals and users needs.
Fast forward 25 years and we now have Agile, Lean and Design Thinking methodologies. The evolutionary mix of these ideas has culminated a few new kids on the block: Design Sprints and its spin-off – Discovery Sprints. When we introduce Design Thinking into the early stages of the software process, we are introducing a user-centered mindset of design.
So why use Discovery Sprints? Plain and simple, they help to build great software products by directing all your efforts, from start to finish, towards a clear end goal.
The Role of Discovery Sprints in the Software Process
At Gistia, Discovery is part of a bigger method for developing customized digital solutions. Discovery is the first phase of our user-centric Agile method, followed by Engineering and Delivery phases.
Every phase of the method is executed in sprints. Sprint is the Scrum term for iteration or cycle — a period of time between one week and one month (usually two weeks) within which the development team builds and tests a part of the product. Sprints give us the power to deliver useful features a few weeks after a project kickoff. Before a project starts we run a 1-2 week Discovery Sprint giving us some ammo to create an initial set of backlog items.
Engineering Sprints are Agile development sprints. They transform backlog items into releasable software features.
Delivery Sprints are composed of continuous integration and continuous delivery activities, as well as user acceptance testing and issue reporting. Additional requirements and details are added through smaller, shorter Discovery Sprints.
The project is managed as a continuous loop of Discovery → Engineering → Delivery.
The Discovery Sprint is used to help our team understand the problem at hand. We aim to align the business strategy, identify the users’ needs and pain points, propose solutions, and validate these solutions. Having a clear understanding of the business problem allows your team to address the project needs in the shortest possible amount of time.
During the Discovery Sprint, we must identify the main functionalities of the product being developed so we can create a development plan. This includes making high-level estimates and assessing if we have the information we need to start planning the specific needs of the project.
Discovery Sprints are all about answering important questions. But what are the right questions to ask? There are several important questions that need answered when we start a new software project. Identifying the key areas is the first step.
When framing the problem, our Discovery Sprint focuses on two big problem areas. When resolving the first problem area, we are aiming to align project objectives with the Business Strategy. It’s important to understand the business context and opportunities before we begin building. This helps to prepare for the next problem area, User Experience.
Here are some questions used to define Business Strategy:
- Why are we doing this project?
- What are the business goals?
- What does the client want to achieve? Why? How?
- What business value does this software product provide?
- What problems are we trying to solve?
- What value does the user achieve?
- What is the market size?
- Who are the main competitors?
The central aspect of user-centric thinking is to understand the user’s current state. In other words, how do they perform their jobs? What are their pain points, problems, and desires?
Next, we design the future state. By using storyboards, journey maps, user stories, listing and tracking jobs to be done, etc., we are able to determine where the project is headed and what we would like to build.
Here are some questions we use to map out our plan for addressing the User Experience:
- Who are we trying to solve problems for?
- What are their needs?
- What problems are they trying to solve?
- What tasks are they trying to perform or complete?
- What undesired situations or conditions could they experience before, during and after getting the job done?
Adding the Details
Once we know what we are building, how we are supporting business goals and have an idea of how to satisfy users needs, it’s time to add some details to the requirements.
Technical Architecture is concerned with the technological aspects of the project we are building. It defines how the solution to the business problem will be built. There are many things to consider like operating systems, platforms, network topology, devices, interfaces to other systems, frameworks, libraries, tools, programming languages, etc. Not every technological aspect has to be defined up-front, but we need to at least reach the minimum technical specifications to evaluate viability and feasibility.
Common questions to help define Technical Architecture needs:
- Does this product interface with other systems?
- What are the hardware, software, data storage and network requirements?
- What are the security, privacy, localization, logging, audit and control requirements?
- What are the disaster recovery, availability and capacity requirements?
- Do we need to define operational procedures?
Existing Systems Evaluation
Sometimes engineers engage in projects that upgrade or replace an existing system. When this is the case, it’s important to collect as much information and data as possible:
- Does this system have existing documentation in the form of manuals, diagrams, help pages, operating procedures, etc?
- Can a data model from the existing system be created?
- What functions does this system perform?
- Does this system interface with other systems?
- Can the technical architecture of this legacy system be described?
Start talking about Quality during Discovery. It helps define your success metrics up front, ensure requirements are valid and put a test plan in place.
Quality related questions may be:
- How will we monitor and assess performance?
- What are the success metrics?
- What are the Key Performance Indicators?
- What is the acceptance criteria for each requirement?
- What are the requirements for the testing environment?
- How will we evaluate usability?
Sometimes the Discovery phase demands the creation of a proof-of-concept. A proof-of-concept, as the name implies, has the sole purpose of verifying if a certain concept, idea or technology can be used for the development of the product. It’s different than a prototype. POCs are developed by the Engineering team. They are also responsible for defining any required development tools. To validate there is one question to ask:
- Are there any ideas, concepts, or technologies that need to be tested or validated before development?
It’s up to you and your company to decide on the best approach to elicit requirements of a new software product. Our method makes use of techniques and artifacts that respond to most — if not all — of the outstanding questions described above. As a strategy to mitigate requirements, we made the decision to prioritize a more positive, constructive mindset. This is the result of having a design over systems mindset. A design mindset brings the questions closer to the business and the user. They are the two customers who we need to consider.
By using some of the ideas outlined in this article, we invite you to exercise these techniques and draft a Discovery framework for your own project sessions. We are confident it will be a rewarding and successful exercise.
Using guidelines from Discovery Sprints and the disciplines from design, I feel a sense of confidence. The dream of becoming a Systems Analyst, well, that is history. Developing a Design mindset and using the Discovery Sprint approach in our software process has helped me to never look back, and for that, I’m very satisfied. Good luck!