Agile Software Discovery

One of the least respected and underrated parts of software development is the discovery process. It might be because discovery is misunderstood by stakeholders and leadership as a duplicated effort. It might be because a top-heavy process like discovery seems out of place for modern, agile teams. Whatever the reason, thinking of the discovery process as extraneous or even optional is a path to disaster. You may think that statement is dramatic. But when McKinsey studied the success of software projects, the data was equally dramatic. Forty-five percent of IT projects go over budget. Seven percent are late. And a staggering 17% go so poorly they actually put the company itself in danger of failing. A discovery process helps identify problems and mitigate risk. On the surface, it may seem to fly in the face of an iterative approach, but in truth, the discovery itself can include iterative elements that both set the project on the right path and ensure the flexibility required for modern development.

Discovery Process PDF

What Does the Discovery Process Look Like?

An Agile discovery process cycles through multiple stages. It incorporates iteration into each step as well as across the project. Much like the rest of the Agile development process, discovery requires communication to reach the desired outcomes.

Defining the Outcome

Discovery is a little like planning a vacation. The first step to planning a trip is deciding where you want to end up. You may not know right away exactly where you want to go, but you iterate through the characteristics of your destination to help define your vacation. For instance, do you want to go somewhere with snow? Or a warm and sandy beach? Are you looking for a cruise, or to go backpacking? As you define each step, you move closer to understanding the outcome you’re hoping for. A successful trip is one where you arrive at your destination and participate in the kinds of activities you were hoping to do. Defining the outcome of your application or software project is similar. You may not know precisely what you want your destination to be, but you have a general idea. Stakeholders, product teams, and product owners meet repeatedly until the problem that needs to be solved and the outcome of the project is well understood.

Outcomes Lead to Opportunities

Defining your opportunities again mirrors planning a trip. Now that you know where you want to end up, what are some of the activities you might engage in? Your destination has both narrowed your view on what you can do – you won’t be going body surfing in Vail in December – but also opens up opportunities for activities that you weren’t previously aware of. This happens in the Agile discovery process, too. Iterating through options in the opportunity stage clarifies what the solution needs to be and moves the project toward the desired outcome. But it also uncovers opportunities, including ways to make your solution more useful or even whole new audiences that could benefit from the product. Iterating through the definition and design of the product and crystalizing its benefits takes a focused effort. As with defining the outcomes, this stage benefits from revisiting the topic multiple times to iterate through potential opportunities.

The Product Roadmap

Going back to our vacation example, once you’re done planning your destination, you’ll know a number of things. Things like where you’re headed and the kinds of things you’ll need to pack. You’ll have an idea, too, of the kind of activities you can do and may have even discovered a few you didn’t know were available. You’ll also have a rough timeline for when you’ll need to finish certain planning tasks, like booking lodging, transportation, rentals, and so forth. In the solution phase of the Agile product discovery process, you’ll have defined where you’re going and the opportunities that the solution offers. You’ll have a prioritized list of features that will get you to the defined outcome. And you’ll know if your solution is going to solve the pain points you intended to address. The product roadmap will also outline a path to success in terms and language that the business can understand and get behind. Because of the time spent in discovery the product team can develop a plan that is usable, feasible, and well-designed, without yet having gotten into the details of how to develop the solution. The result of this process is a clear path forward that avoids rigidity and promotes flexibility throughout the development process. It also offers a framework that can be iteratively revisited throughout the project. Outcomes, opportunities, and the product roadmap can be re-examined and discussed regularly to ensure that the product’s initial development and it’s future enhancements meet the needs of the user or alleviate the business’s pain points.

Is discovery a pain point for your team?

We’re here to be a resource for you! Whether you need a second opinion on your process, need help with your discovery and planning workshops, or you're looking to bring in a partner for the entire thing. Contact us to schedule an initial call!
Let's Talk Discovery

Questions & Activities During Discovery

Time spent in discovery defines not only what is being built, but offers answers that drive what the product will look like, the functionality needed, and priorities, timelines, and even costs associated with development.

To get to that point, however, the project team and stakeholders need to step through several activities that will clarify the answers to key questions. Understanding those questions upfront will eliminate going down unproductive paths later in the project, or exploring features and functionality that don’t apply to your audience.

Not all activities that can be part of discovery are part of every project. But this phase can include any of the following, as long as they lead to a workable definition of the project’s needs:

  • Review of existing architecture and legacy code
  • User definition, user research, and user behaviors
  • Associated research, both external and any internal documentation
  • Wireframing and mock-ups of the application interface
  • Analysis of the market and need
  • Brainstorming of features, functionality, and use cases
  • Stakeholder interviews
  • Competitive analysis

The purpose of these activities is to answer questions that are important to developing the deliverables for this phase of the project:

  • Who is the software for?
  • When will they need it?
  • How and when will they use it?
  • Where will it be implemented and what platforms will it run on?
  • Does the project have competition? Who, and what do they do?
  • Is there a hard deadline?
  • What does project success look like?
  • What is the scope of the project?
  • What security is needed? Will there be a login?

Discovery Phase Deliverables

Once discovery is complete, you’ll have your plan to move forward. That doesn’t mean that the project can’t evolve and change during development. But discovery gives you the solid foundation to make changes from, instead of up-ending the entire product when the market changes or new customer demands come to light.

Much like the discoveries activities, the deliverables will be defined by what the project needs. But generally speaking, this phase will result in several of the following:

  • A solution vision document: A concise description of what the project purpose is and what it’s meant to accomplish.
  • Requirements: Your requirements could take a number of forms, including functionality requirements, use cases, epics, and user stories.
  • Architectural design: These plans may include database, integration requirements, systems, dependencies, and so forth.
  • User interface design: This may include wireframes and mockups, brand guidelines, or a user dictionary.
  • Risk assessment: A risk assessment could include the impacts of competitors, delays in release, or dependencies on other systems or resources.
  • Release plan: With an agile project, a release plan defines what the sprints will look like and reflects the initial priorities defined for release.
  • Prototype or proof of concept: Discovery may include an MVP or a proof of concept, offering a quick version of the solution to illustrate its viability.
  • Cost estimates: With a good idea of the solution’s requirements, a cost estimate can be created that is far more accurate than one done without a discovery, reducing the chance of surprises.