DomenikaBo, CC BY-SA 4.0 <​>, via Wikimedia Commons

User Stories as a negotiation between problems and solutions

Agile software development radically changed the nature of software creation. One of the hallmarks of agile is the creation of small increments of end user functionality as opposed to creating software in one or few large portions. Agile also included many other innovations such as starting with confirmatory tests as opposed to creating tests after construction and creating self managed teams as opposed to traditional command and control. There was an earlier, parallel movement in understanding the design and creation of mechanical objects, including building architecture, product design and graphic communication. One of the major contributors to that movement was Bryan Lawson. In Lawson’s book, ‘ How Designers Think ‘[1], he explains the characteristics of design problems, solutions and the process. In this article I have explained Lawson’s ideas on design problems, solutions and the process. Understanding the fundamental nature of problems and solutions can greatly benefit the power of agile increments/user stories.

Context: Iterations, Construction, Teams

  1. Agile has made major contributions to organization, culture, collaboration and group dynamics. The ideas presented in this article are not in conflict with the work of a team.
  2. The design of a building includes the aspects of construction. In software, (user interface) design is a separate and often optional activity. The use of the word ‘design’ in this article includes all aspects of designing and implementing a user story. For this article, let’s assume there is no separate UI/UX designer.

As you read the rest of this article, think of implementing a single user story. This isn’t about using an agile retrospective to create a feedback loop.

Problems vs. Solutions?

Design problems and solutions are different. When you design a library, is the library the problem or the solution? Does the client specify how the library should look like? In that case is he specifying the problem or the solution? In a student problem of designing a library, the student starts by asking about the broader purpose of the project. Even when a client has preconceived ideas about a solution, designers may want to understand the broader goals. A supportive client will participate in the process rather than be fixated on his solution.

In agile software development, there is similar thinking of specifying user stories as a customer need rather than a solution, i.e., what will be built. However, there is often confusion between a traditional specification and a user story.

Solutions improve problem understanding and create new problems

Problems are subjective

Thinking approaches redefine the problem

Developers should contribute to problems as much as clients

The role of the user has got a lot of attention in agile development. However, sometimes developers mistake this to mean that the user will provide a static problem definition and later validate it.

Solutions always involve compromise

Design solutions are always holistic

Problem solving is a non-linear, endless process

The nature of problem solving and implementation of user stories

  • Solutions will often create new problems
  • Interpretation of problems is subjective
  • Solutions are based on subjective value judgment (‘Quality is value to some person’).
  • Developers should actively contribute to problems. This is part of problem solving.
  • The design process, starting from understanding the problem, is an active collaboration between developer and client. (This is because solution development exposes flaws in understanding problems and that solutions may create new problems.)
  • There are many approaches to thinking about problems. (different from thinking about solutions)
  • Solutions always involve compromise.
  • Design solutions are holistic.
  • There is no single infallible process of implementing user stories
  • There is no end to the process of implementing user stories
  • User stories are a negotiation of problems and solutions

Mechanical artifacts such as buildings or industrial products cannot be created using the approach of agile user stories. Understanding the nature of problems and solutions used by architects and designers coupled with the concept of user stories can result in creating very powerful software designs.

How Designers Think

  1. Lawson, B. R., (2005), How Designers Think, Fourth Edition
  2. Page Rank Algorithm, Wikipedia.
  3. Figure 3.1, A map of the design process according to the RIBA plan of work, Page 35, Lawson, B. R., (2005), How Designers Think, Fourth Edition
  4. Weinberg, Gerald M., Quality Software, Volume 1, How Software is Built, Section 1.3
  5. Eberhard, J. P. (1970). We ought to know the difference. In Emerging Methods in Environmental Design and Planning. Cambridge, Mass, MIT Press, quoted on Page 56, How Designers Think (2005), Fourth Edition
  6. Page 56, Lawson, B. R., (2005), How Designers Think, Fourth Edition
  7. Bryan Lawson’s biography on the University of Sheffield.

Originally published at

Software testing, project management, managing testers