Running a product team

Lessons 2 to 5 described how a product team decides what to build. This lesson is about the team itself: who does what, how the backlog is kept healthy, how goals connect daily work to outcomes, and how the PM or product owner works with stakeholders. CMPUT-301 introduced Scrum's roles, events and artifacts as a process model; here we look at them from the product side, focusing on the practical craft of the product owner and on the habits that keep a team aligned. For the broader people side of leading teams, such as motivation, conflict and team development, see PMP-120 and BUS-220.

The product owner role

In Scrum the product owner (PO) is accountable for maximizing the value of the product resulting from the team's work. The 2020 Scrum Guide gives the PO four responsibilities for the product backlog: developing and explicitly communicating the product goal, creating and clearly communicating backlog items, ordering backlog items, and ensuring the backlog is transparent, visible and understood. The PO may delegate work but remains accountable, and the Guide is clear that the PO is one person, not a committee. Organizations must respect the PO's decisions, which are visible in the content and ordering of the backlog.

In practice, the PO role varies. In a product company the PO is often a PM who also does discovery, strategy and stakeholder management. In some large organizations the PO is a narrower role focused on backlog management while a separate PM owns strategy. In client projects such as Driftwood's, two POs effectively exist: someone on the client side who knows the business and has authority to make decisions, and someone on the delivery team who translates those decisions into a workable backlog. Making these roles explicit early prevents confusion; lesson 11 returns to client governance.

Backlog refinement

Backlog refinement (formerly grooming) is the ongoing activity of breaking down and adding detail to backlog items so they are ready for selection in a coming sprint. It is not a formal Scrum event but a continuous practice, and the Scrum Guide notes it usually consumes no more than about 10 percent of the developers' capacity. Most teams hold one or two short sessions per week where the PO presents upcoming items, developers ask questions, the team splits large items, adds acceptance criteria and estimates. The aim is to keep roughly one to two sprints of ready work at the top of the backlog: enough to plan confidently, not so much that work goes stale.

A healthy backlog has a shape sometimes described as an iceberg or the DEEP acronym, from Roman Pichler and Mike Cohn: detailed appropriately, estimated, emergent and prioritized. Items near the top are small, detailed and ready; items further down are larger and vaguer, such as epics or themes like reservations, and become detailed only when they approach the top. Detailing everything up front wastes effort, since much of it will change after discovery.

Definition of ready and definition of done

A definition of ready (DoR) is a team agreement on what an item needs before the team will commit to it in a sprint. It is not part of the Scrum Guide and should be used with care, because a strict DoR can turn into a gate that blocks collaboration. Used well, it saves sprints from being derailed by items that turn out to be unclear, blocked or too large. A typical DoR asks: is the value stated, are acceptance criteria written, is the item small enough to finish in a sprint, are dependencies resolved, and are designs available if needed? The code checks a small Driftwood backlog against such a list.

# Check backlog items against a team's definition of ready (invented backlog).
backlog = [
    {"id": "DF-12", "title": "Show delay banner on home page", "value": "reduce calls",
     "criteria": ["banner appears within 1 min of status change", "readable by screen readers"],
     "size": 3, "blocked_by": [], "design": True},
    {"id": "DF-15", "title": "SMS alert at 90% deck capacity", "value": "fewer missed sailings",
     "criteria": ["alert sent once per sailing"], "size": 8, "blocked_by": ["DF-21"], "design": True},
    {"id": "DF-18", "title": "Improve schedule page", "value": "",
     "criteria": [], "size": None, "blocked_by": [], "design": False},
    {"id": "DF-21", "title": "Deckhand count entry screen", "value": "enable live counts",
     "criteria": ["one-tap increment", "works offline", "syncs within 30 s"],
     "size": 5, "blocked_by": [], "design": True},
    {"id": "DF-24", "title": "Island terminal payment info", "value": "fewer tourist surprises",
     "criteria": ["lists accepted payment methods"], "size": 13, "blocked_by": [], "design": True},
]
MAX_SIZE = 8
def problems(item, done_ids):
    p = []
    if not item["value"]:
        p.append("no stated value")
    if len(item["criteria"]) == 0:
        p.append("no acceptance criteria")
    if item["size"] is None:
        p.append("not sized")
    elif item["size"] > MAX_SIZE:
        p.append(f"too big ({item['size']} > {MAX_SIZE}), split it")
    open_blocks = [b for b in item["blocked_by"] if b not in done_ids]
    if open_blocks:
        p.append("blocked by " + ", ".join(open_blocks))
    if not item["design"]:
        p.append("no design")
    return p
done = set()
ready_size = 0
for it in backlog:
    issues = problems(it, done)
    status = "READY" if not issues else "not ready: " + "; ".join(issues)
    if not issues:
        ready_size += it["size"]
    print(f"{it['id']} {status}")
print(f"ready work: {ready_size} points; at about 12 per sprint that is "
      f"{ready_size / 12:.1f} sprints of runway")

DF-12 READY
DF-15 not ready: blocked by DF-21
DF-18 not ready: no stated value; no acceptance criteria; not sized; no design
DF-21 READY
DF-24 not ready: too big (13 > 8), split it
ready work: 8 points; at about 12 per sprint that is 0.7 sprints of runway

In this output, DF-15 is blocked by DF-21, so the team should pull DF-21 first, and DF-24 is too large and should be split, perhaps into a cash and card note and a separate accessibility item. DF-18 is a classic vague item: improve schedule page has no value, criteria or size, and needs a refinement conversation, ideally grounded in the usability test results from lesson 5.

The definition of done (DoD), by contrast, is a formal part of Scrum: a shared description of the quality an increment must meet to be releasable. CMPUT-301 covered the DoD from a process perspective. From a product perspective, the DoD is how the PO knows that done means usable by real travelers. Team Lumen's DoD includes code reviewed, automated tests passing, accessibility checks at WCAG 2.2 level AA for changed screens, deployed to staging, product analytics events added, and release notes drafted. Acceptance criteria are specific to one item; the DoD applies to every item.

Product goals and sprint goals

The 2020 Scrum Guide introduced the product goal: a long-term objective for the product that the backlog serves. Each sprint also has a sprint goal: a single objective that gives the sprint coherence and flexibility. A good sprint goal describes an outcome or capability, not a list of tickets. Complete DF-12, DF-21 and DF-30 is a task list; Office staff can post a delay once and travelers see it on the home page within one minute is a goal. With a real goal, the team can renegotiate the detailed work during the sprint while still delivering what matters.

Sprint goals connect upward to quarterly objectives. Many product organizations use objectives and key results (OKRs), popularized by Intel and Google. An objective is qualitative and inspiring, such as travelers trust Driftwood's information; key results are measurable, such as delay calls fall from 220 to 110 per week. Key results should be outcomes, not outputs: launched the alert system is an output; 95 percent of alerts arrive within two minutes is closer to an outcome. OKRs are usually scored at the end of the period on a 0 to 1 scale, and Google's practice treats about 0.6 to 0.7 as a good score for ambitious goals.

# Score quarterly key results on the 0.0-1.0 scale (invented end-of-summer data).
okrs = {
    "Passengers trust Driftwood's information": [
        ("Phone calls about delays per week", 220, 110, 130),   # start, target, actual
        ("Schedule page accuracy (audited)", 0.92, 0.99, 0.985),
        ("Delay alerts reach subscribers within 2 min", 0.0, 0.95, 0.97),
    ],
    "Fewer missed sailings for commuters": [
        ("Commuters turned away per week", 35, 20, 29),
        ("Commuters subscribed to capacity alerts", 0, 300, 210),
    ],
}
for objective, krs in okrs.items():
    print(objective)
    scores = []
    for name, start, target, actual in krs:
        s = (actual - start) / (target - start)
        s = max(0.0, min(1.0, s))
        scores.append(s)
        print(f"   {s:.2f}  {name}")
    print(f"   objective average {sum(scores) / len(scores):.2f}")

Passengers trust Driftwood's information
   0.82  Phone calls about delays per week
   0.93  Schedule page accuracy (audited)
   1.00  Delay alerts reach subscribers within 2 min
   objective average 0.92
Fewer missed sailings for commuters
   0.40  Commuters turned away per week
   0.70  Commuters subscribed to capacity alerts
   objective average 0.55

Working with stakeholders

A PM spends much of their time with people outside the team: the client owner, office staff, deckhands, the finance person who approves invoices, the regulator who must approve any change to how sailings are announced. Stakeholder management starts with mapping: list stakeholders and place them on a grid of influence against interest. High influence, high interest stakeholders, like Driftwood's owner, are managed closely with frequent involvement in decisions. High influence, low interest stakeholders, like the regulator, are kept satisfied with concise updates on what affects them. Low influence, high interest stakeholders, like the island community association, are kept informed. Others are monitored. PMP-120 covers stakeholder engagement in depth.

Regular rituals keep stakeholders aligned. The sprint review is the main one in Scrum: the team shows working software to stakeholders and gathers feedback that may reorder the backlog. A short written weekly update, covering progress against the sprint goal, decisions needed, risks and what is next, keeps busy clients informed between reviews. A monthly roadmap review revisits priorities. In each, the PM's job is to make trade-offs visible and get decisions made, not to report activity.

Team structure and the product trio

Modern product teams are usually cross-functional and long-lived: one team owns one product area end to end, including discovery, delivery and operations. The book Team Topologies by Matthew Skelton and Manuel Pais calls these stream-aligned teams and argues that minimizing hand-offs and cognitive load matters more than any org chart. Inside the team, the product trio of PM, designer and tech lead share discovery. The tech lead is involved early because feasibility risks, like car counting, often decide which solutions are realistic. For a student team, roles rotate less formally, but naming who owns the backlog, the design and the architecture still prevents gaps.

Worked examples