Design and Scrum


UI/UX Design with Agile teams


There is a high degree of overlap with the approach of Design thinking and Agile, particularly Scrum. The emphasis on using an empirical process with fast feedback to confirm ideas is similar. There is a natural alliance between the Design and Product focus of Agile frameworks, particularly Scrum.

There are broadly three modes of working, with the optimal value having the UI/UX professionals working as part of the Development team.

Design Thinking

Design thinking is a human centred rapid prototype innovation framework. It was adapted for business purposes by David M. Kelley from Stanford. It is based on the understanding that design problems are inherently complex, and there are multiple valid ways to solve a problem, particularly unclear or ill defined problems.

There are 4 principles:

  • The human rule – all design activity is ultimately social in nature
  • The ambiguity rule – design thinkers must preserve ambiguity
  • The re-design rule – all design is re-design
  • The tangibility rule – making ideas tangible always facilitates communication

This leads to design innovation that guides the winnowing of ideas to the highest desireability, while being achievable.

Technology, Humanity, Business

The process for Design Innovation is non-linear, and follows the broad framework of:


There is a vast range of tools and techniques that can be used in each stage, and as this is non-linear can influence any other stage.

Fast light weight prototypes that can be quickly validated with users is key. Ideas are refined or discarded, with each experiment being validated with representative users, without the high cost of full development and release.

This helps the designer ensure that we build the right thing.

Agile Development (with Scrum focus)

Within Agile development, the focus is on building small, regular increments of high quality. This allows the business to respond to changes in the market, and innovate.

Scrum is the most popular of the Agile frameworks, as it is a process framework that provides visibility and risk management when used correctly.

The key to this is the clarity of the roles for the people involved, and the discipline of the timebox. The three roles have clear responsibility

Product Owner: The single person responsible for the “What”. To build the right “thing”.

Development Team: The cross-functional, self-organising team responsible for the “How”. To build the “thing” right.

Scrum Master: The single person responsible for the framework being used correctly.

As with Design thinking, the challenge is working in a complex domain – often with unclear requirements. This is resolved by using a Product Backlog (ordered list of requirements) that is gradually refined

Ways of Working

Design Prototyping

This mode of working is best for strategic or formative work, where the Design team are working to find the initial state or flow. It allows for fast learning and testing of ideas, however will demand a longer handover to development.

Inherently phased in nature, there is risk of not being feasible in terms of Return on Investment as the development team is not engaged.

Design to Development

Having the Design team work in a sprint before the development team, out of cadence. The design work is then fed in to the development process as ready work.

This mode is useful when the Product Map is being defined, and the user personas being reified to build a richer user picture.

The design team need to work closely with the Product Owner to focus on the items at the top of the Backlog to minimise waste due to rework.

Integrated Team

This mode of working will have the designer working collaboratively within the Development Team. This will grow the common understanding of the design and product elements, and the close working will allow a prompt and effective response to any impediments.


The common aspect in all ways of working is to have a clear understanding between all 3 disciplines as to how detailed an item (story) needs to be before the Development Team take it in to build. This will enable each discipline to ensure they help the flow of ideas through to the finished product to proceed with minimal disruption

Role Interactions and artefacts

Product Owner

The Product Owner will need to shape the direction that the design and build are working towards, and listening to them for guidance. The artefacts that the Product Owner will use to focus the efforts are:

1. Product Vision

a. Elevator Pitch

b. Product Box

c. Product Canvas

2. Product Roadmap

3. Product Backlog

a. Collectively and collaboratively refined

3. Product Strategy

a. Aligned with the business and IT strategy

It is critical that the Product Owner is empowered to focus all the creative efforts on the stories and tasks that will provide the greatest business benefit.

Design Team

The design team need to own the usability and desirability of the human interaction, and guide the Product Owner and the Development team.

They will generate and maintain several of the following artefacts in the product lifecycle

  1. Empathy Map
  2. User Personas
  3. Wireframes
  4. Workflows
  5. Product Canvas
  6. Prototypes of increasing fidelity

Development Team

The development team are responsible for creating the completed increment of the product, in accordance to the Product Owners decision, as close as technically feasible to the Design. They will need to engage in refinement with the Product Owner and Designer in order to build a common understanding of what is being made.

The Development Team are responsible for:

  1. Definition of Done, and the quality that entails
  2. The increment at the end of each Sprint


There is a strong alignment between Design Thinking and Agile. When the disciplines collaborate focussing on the core responsibilities of each role, then the optimal product decisions will be made, reducing waste, and increasing the potential to delight the customer while innovating.



Connect with Advanced Product Delivery.

APD offer private, tailored training courses as well as business agility and coaching. Our public training courses are delivered by practicing Agilists: Product Owners, Scrum Masters and coaches who are expert trainers and facilitators.

Whether you are looking to become a #scrummaster or #agilecoach, we have a range of internationally certified and recognised #agiletraining courses that are perfect for you. Visit Professional Scrum Training courses for more information.

If you are looking for professional, deeply experienced and skilled #agilecoaches and #agileconsultants to help you transition from traditional #projectmanagement to #agile #productdevelopment, we’ve got the ideal team to help you make that transition a success. Visit our Agile Coaching section to find out more about us.

If you have identified Lean Agile Procurement as a great opportunity to enhance #agility within your organization, visit the Lean Agile Procurement Training course or Lean Agile Procurement coaching page.

#agile #scrum #agilecoach #agileconsultant #agiletraining #agilescrumtraining #scrumtraining #scrumcertification #scrummaster #productowner #leanagileprocurement #apd #businessagility #organizationalagility #productdevelopment #projectmanagement #agileprojectmanagement #agileproductdevelopment

You may also like...

Stakeholders and Scrum Team
Agile Coach

Project Managers and Scrum

This blog addresses the confusion around the role of Project Managers in Scrum, emphasizing that Scrum does not have a Project Manager role. Instead, responsibilities are distributed among the Product Owner, Development Team, and Scrum Master. It explores how Project Managers can adapt by collaborating within Scrum or transitioning to roles like Product Owner or Scrum Master, and highlights the fundamental differences between predictive and empirical management models.

Read More »

Latest Blog Posts

Image of a webinar

Questions from Scrum.Org webinar

This blog addresses the questions that could not be answered in the webcast on Procurement in Agile Transformations. There are many challenges that parallel the agile transformations.

Read More »