Scrum and Other Product Team Practices


A solid foundation of team-level organization and practice is essential as an organization scales up. Bad habits (like accepting too much work in the system, or tolerating toxic individuals) will be more and more difficult to overcome as the organization grows.

The Concept of Collaboration

Team collaboration is one of the key values of Agile. The Agile Alliance states that: “A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis.”

Teams are multi-skilled, share accountability, and individuals on the team may play multiple roles [Agile Alliance 2015]:

Face-to-face interactions, usually enabled by giving the team its own space, are essential for collaboration. While there are various approaches to Agile, all concur that tight-knit, collaborative teams deliver the highest value outcomes. However, collaboration does not happen just because people are fed pizzas and work in a room together. Google has established that the most significant predictor of team performance is a sense of psychological safety. Research by Anita Woolley and colleagues [Woolley et al. 2015] suggests that three factors driving team performance are:

  • Equal contribution to team discussions (no dominant individuals)

  • Emotional awareness – being able to infer other team members’ emotional states

  • Teams with a higher proportion of women tend to perform better (the researchers inferred this was due to women generally having higher emotional awareness)

Other research shows that diverse teams and organizations are more innovative and deliver better results; such teams may tend to focus more on facts (as opposed to groupthink) [Rock 2016]. Certainly, a sense of psychological safety is critical to the success of diverse teams, who may come from different cultures and backgrounds that do not inherently trust each other.

The collective problem-solving talent of a diverse group of individuals who are given space to self-organize and solve problems creatively is immense, and very possibly the highest value resource known to the modern organization.

Two current schools of thought with much to say about collaboration are Lean UX and Scrum.

Lean UX

Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed.
— Jeff Gothelf
Lean UX

Lean UX is a term coined by author and consultant Jeff Gothelf and Josh Seiden [Gothelf & Seiden 2013], which draws on three major influences:

  • Design thinking

  • Agile software development

  • Lean Startup

We briefly discussed Lean Startup in Digital Value, and the history and motivations for Agile software development in Application Delivery. We will look in more depth at product discovery techniques, and design and design thinking subsequently. However, Lean UX has much to say about forming the product team, suggesting (among others) the following principles for forming and sustaining teams:

  • Dedicated, cross-functional teams

  • Outcome (not deliverable/output) focus

  • Cultivating a sense of shared understanding

  • Avoiding toxic individuals (so-called “rockstars”, “gurus”, and “ninjas”)

  • Permission to fail

(Other Lean UX principles such as small batch sizes and visualizing work will be discussed elsewhere; there is significant overlap between Lean UX and other schools of thought covered in this document).

Lean UX is an influential work among digital firms and summarizes modern development practices well, especially for small, team-based organizations with minimal external dependencies. It is a broad and conceptual, principles-based framework open for interpretation in multiple ways. We continue with more “prescriptive” methods and techniques, such as Scrum.


Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products. [Sims & Johnson 2012]
— C. J. Sims/Hillary L. Johnson
Scrum: A Breathtakingly Brief and Agile Introduction
There are no tasks; there are only stories. [Sutherland & Sutherland 2014]
— Jeff Sutherland
Scrum: The Art of Doing Twice the Work in Half the Time

One of the first prescriptive Agile methodologies you are likely to encounter as a practitioner is Scrum. There are many books, classes, and websites where you can learn more about this framework; Sims & Johnson 2012 is a good brief introduction, and Rubin 2012 is well suited for more in-depth study.

“Prescriptive” means detailed and precise. A doctor’s prescription is specific as to what medicine to take, how much, and when. A prescriptive method is similarly specific. “Agile software development” is not prescriptive, as currently published by the Agile Alliance; it is a collection of principles and ideas you may or may not choose to use. By comparison, Scrum is prescriptive; it states roles and activities specifically, and trainers and practitioners, in general, seek to follow the method completely and accurately.

Scrum is appropriate to this Competency Area, as it is product-focused. It calls for the roles of:

  • Product owner

  • Scrum master

  • Team member

and avoids further elaboration of roles.

The Scrum product owner is responsible for holding the product vision and seeing that the team executes the highest value work. As such, the potential features of the product are maintained in a “backlog” that can be re-prioritized as necessary (rather than a large, fixed-scope project). The product owner also defines acceptance criteria for the backlog items. The Scrum master, on the other hand, acts as a team coach, “guiding the team to ever-higher levels of cohesiveness, self-organization, and performance” [Sims & Johnson 2012]. As Roman Pichler notes: “The product owner and Scrum master roles complement each other: The product owner is primarily responsible for the “what” – creating the right product. The Scrum master is primarily responsible for the “how” – using Scrum the right way” [Pichler 2010].

Scrum uses specific practices and artifacts such as sprints, standups, reviews, the above-mentioned concept of backlog, burndown charts, and so forth. We will discuss some of these further in [Work Management] and [Coordination and Process ] along with Kanban, another popular approach for executing work.

In Scrum, there are three roles:

  • The product owner sets the overall direction

  • The Scrum master coaches and advocates for the team

  • The development team is defined as those who are committed to the development work

There are seven activities:

  • The “Sprint” is a defined time period, typically two to four weeks, in which the development team executes on an agreed scope

  • Backlog Grooming is when the product backlog is examined and refined into increments that can be moved into the sprint backlog

  • Sprint Planning is where the scope is agreed

  • The Daily Scrum is traditionally held standing up, to maintain focus and ensure brevity

  • Sprint Execution is the development activity within the sprint

  • Sprint Review is the “public end of the sprint” when the stakeholders are invited to view the completed work

  • The Sprint Retrospective is held to identify lessons learned from the sprint and how to apply them in future work

There are a number of artifacts:

  • The product backlog is the overall “to-do” list for the product

  • The sprint backlog is the to-do list for the current sprint

  • Potentially Shippable Increment (PSI) is an important concept used to decouple the team’s development activity from downstream business planning; a PSI is a cohesive unit of functionality that could be delivered to the customer, but doing so is the decision of the product owner

Scrum is well grounded in various theories (process control, human factors), although Scrum team members do not need to understand theory to succeed with it. Like Lean UX, Scrum emphasizes high-bandwidth collaboration, dedicated multi-skilled teams, a product focus, and so forth.

The concept of having an empowered product owner readily available to the team is attractive, especially for Digital Practitioners who may have worked on teams where the direction was unclear. Roman Pichler identifies a number of common mistakes, however, that diminish the value of this approach [Pichler 2010]:

  • Product owner lacks authority

  • Product owner is overworked

  • Product ownership is split across individuals

  • Product owner is “distant” – not co-located or readily available to team

Scrum and Shu-Ha-Ri

In the Japanese martial art of aikido, there is the concept of shu-ha-ri, a form of learning progression.

  • Shu: following the rules of a given method precisely, without addition or alteration

  • Ha: learning the theory and principles of the technique

  • Ri: creating your own approaches and adapting the technique to circumstances

Scrum at its most prescriptive can be seen as a shu-level practice; it gives detailed guidance that has been shown to work; see Fowler 2014a and Cockburn 2006.

More on Product Team Roles

Boundaries are provided by the product owner and often come in the form of constraints, such as: “I need it by June”, “We need to reduce the per-unit cost by half”, “It needs to run at twice the speed”, or “It can use only half the memory of the current version.” [Cohn 2009]
— Mike Cohn
Succeeding with Agile Software Development Using Scrum

Marty Cagan suggests that the product team has three primary concerns, requiring three critical roles [Cagan 2018]:

  • Value: product owner/manager

  • Feasibility: Engineering

  • Usability: User Experience (UX) design

Jeff Patton represents these concepts as a Venn diagram (see The Three Views of the Product Team, similar to Patton 2014).

venn diagram
Figure 1. The Three Views of the Product Team

Finally, a word on the product manager. Scrum is prescriptive around the product owner role, but does not identify a role for product manager. This can lead to two people performing product management: a marketing-aligned “manager” responsible for high-level requirements, with the Scrum “product owner” attempting to translate them for the team. Marty Cagan warns against this approach, recommending instead that the product manager and owner be the same person, separate from marketing (Cagan 2018).

In a subsequent section, we will consider the challenge of product discovery – at a product level, what practices do we follow to generate the creative insights that will result in customer value?

Evidence of Notability

Product team structure and practices are widely debated and discussed in the industry, particularly in the Agile community. Notable conferences include Agile Alliance and Global Scrum Gathering. Many books are published on Scrum and related product team organization topics; e.g., Rubin 2012, Gothelf & Seiden 2013, Sutherland & Sutherland 2014.


Product team structure and practices are only relevant when there is a concept of product. Some digital work may be framed as projects, where structures are temporary and objectives are more constrained.

Related Topics