Starting with a problem for agile software development

by David Burkett, Dec 19, 2019

This article is for anyone considering or preparing to begin a software development project. It intends to show you how to start with a problem-driven approach against a planned or traditionally linear plan. The context of this will be shared through our learnings and experimentation over numerous software projects. 

As a Web and Mobile app development company WorkingMouse uses our Way of Working as a functional guide on how to deliver Agile projects. At the start of 2019, we observed a pattern of lower customer satisfaction at the beginning of our scope process. To address this we decided to experiment in improving our Brief process that precedes project Scope. The outcome from this has been a change to our Discovery Workshop process which we call 'starting with a problem'. 

Old Approach

To fully comprehend the value delivered in changing the process it is important to firstly understand the old Brief process. The old process involved capturing what we define as a list of 'Epics'. These are large volumes of work that could then be broken down and prioritised into smaller 'User Stories' during scoping. This essentially amounted to an unvalidated wish list based purely upon a single product owner vision. We found scoping from this was taking us too far into a project and its assumed solution. 

The issues that came from the old approach were:

  • Several projects failing to truly capture customers needs and provide a viable solution to their end-users. 
  • Differing expectations between epics at the Brief stage and epics at the Scope stage. 
  • Scoping and building unassumed and unvalidated work.
  • Larger scope which ultimately takes longer, leading to larger estimations, projects and deliverables.
  • Scoping teams felt they were fleshing out a wish list into a product instead of consulting to solve real problems.

To re-align expectations and remove assumed work, we proposed and completed an experiment to change the brief process.

New Approach

Taking inspiration from successful methods (see inspiration below) we pivoted the briefing stage to focus on the customers problem, then their solution.

What this means is that instead of sitting down and formulating a list of 'Epics' the team works with the customer to define a problem statement that when solved, achieves their business goal.

For example, this could mean:

Problem statement: "My users need a way to better track their job progress within my software"

Goal: "Increase productivity, team happiness and managerial tracking"

Moving to this methodology we create a frame of mind for the scoping stage where everyone involved is formulating different approaches to solve the problem. Rather than spending most of their time turning those 'wish-list' items into unvalidated solutions.

The Process

The Discovery Workshop is used to learn and understand: what the customers business goals are, what their goal is for engaging with the customer, what their criteria for success will be and what problem/s they are hoping to solve with this project. 

  1. The team will map out what the relevant user journey is and what steps the business takes to complete the desired outcome so everyone has an understanding of the current process.

  2. We list all of the problems/opportunities we have to solve this using software. 

  3. Team members help the customer focus in on the most pressing problem that they can solve early on to validate.

  4. We ask why. This enables us to remove any abstraction or assumptions through their domain experience that customers may have placed into the statement.

  5. After this, we rapidly iterate the problem statement again until it satisfies all relevant stakeholders and the business process.

  6. Finally, we quantify the problems business case by setting a goal where we can measure value. 

If the customer is coming with a ready solution or a backlog of stories then the team should still focus in on finding the first problem and explain how the scoping team will proceed with identifying a solution from that. It is also important not to get bogged down in any solution generating this early on. Ideas can be recorded to be tested but it is not about forming a solution...yet.

The objective of a brief is to make sure the customer and WorkingMouse can facilitate a good working relationship and build trust (which is the foundation of any agile project). WorkingMouse is looking to ensure that the customer understands how we work and what steps/stages we undertake within our Way of Working.


We do not profess to be the masters of design thinking. We learn from and adapt learning to our process. Therefore it is important to highlight relevant resource we took inspiration from for this. 

'The Design thinking playbook': mindful digital transformation of teams, products and services, businesses and ecosystems/ by Michael Lewrick, Patrick Link and Larry Liefer, published by (2018).
'Sprint how to solve big problems and test new ideas in just five days' by Jake Knapp, published by Google Ventures.


Through this process, we found that our customers are more open to change. Scoping is shortened with smaller deliverables, smaller estimations at the end of the scope and better software for the end-users. We hope you can use this approach for your software projects. Alternatively, contact us to see how we can use the process to help you build software.