Limit Team Mental Workload

From go-ELSE
Revision as of 00:51, 24 January 2024 by Ppugliese (talk | contribs) (Created page with "__NOTOC__ == Description == Ensure that all teams are working with a Mental Workload that they can cope with on a sustained basis. Each team will have a practical limit to the breadth and depth of solution and business domain complexity that they can deal with and maintain a sustained high quality outcome. Factors to balance when considering the practical mental workload limit for a team: * Inherent business domain complexity *Level of Product Owner support * Numbe...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Description

Ensure that all teams are working with a Mental Workload that they can cope with on a sustained basis. Each team will have a practical limit to the breadth and depth of solution and business domain complexity that they can deal with and maintain a sustained high quality outcome.

Factors to balance when considering the practical mental workload limit for a team:

  • Inherent business domain complexity
  • Level of Product Owner support
  • Number of inter-team collaborative relations and their intensity
  • Solution domain skills diversity spectrum required
  • Solution platform complexity and ease of use
  • Solution architecture complexity
  • Team maturity - team cohesion and agility
  • Level of Scrum Master support

Rationale

At scale, there is a higher probability that the potential mental workload will exceed a single team's capacity. Team design must therefore balance a practical distribution of mental workload across teams whilst maximising other team design principles.

This results in:

  • A high learning curve on much of the team's work leading to extended delivery times and less than optimal quality design decisions
  • High stress reducing teams' creativity and motivation levels

Related Principles