Welcome to the Jungle: Where to begin in assessing Scrum Teams

Picture it: you've been dropped like a paratrooper in the middle of a project jungle where the scrum teams are already full speed ahead in working their sprints, but it's more like the sprints are working them... to a slow death march. The never-ending barrage of user story questions is like a thick brush blocking the teams from reaching their goals. Plus, you've been given a "helpful" tip from an insider that some teams are "in need of discipline". How do you dig in and evaluate what's going on without creating more chaos?

In this session, we will discuss who and what to evaluate when making assessments of an Agile team's maturity.


Outline/Structure of the Experience Report


  1. About me
  2. Why bother gauging where teams are?

The Who

  1. Who's on the hot seat?
    • Product Owner
    • Dev Team

The What

  1. Product Owner Assessment
    • Product Vision: does it even exist?
    • Backlog management
    • Backlog Refinement/Grooming
    • Sprint Planning Prep - Definition of Ready
    • Ins and outs of the Sprint Review
    • Stakeholder communication
  2. Dev Team Assessment
    • Scrum Board workflow
    • Definition of Done
    • Team Agreements
    • Daily Scrum effectiveness
    • Backlog Refinement/Grooming
    • Sprint Planning - Estimation
    • Retrospectives

Wrap Up

  1. Now what?
  2. Q&A

Learning Outcome

  1. Understand the who, what and whys of assessing team maturity for established teams
  2. Practical recommendations for where to start your evaluation when looking at Agile teams

Target Audience

Scrum Masters and Coaches

Prerequisites for Attendees

Knowledge of Scrum - ceremonies, roles and artifacts

schedule Submitted 2 years ago

  • 60 Mins

    Are you - or worse, your bosses - starting to doubt this Agile thing? Are your software teams proficiently delivering every two weeks and yet it just doesn't seem to make much of a difference to the bottom line?

    Most organizations begin their foray into Agile with software development and that makes sense - after all, the Agile Manifesto focuses on “working software.” Unfortunately, though, this is often also where the Agile journey comes to a grinding halt. Management confines Agile to a small box labeled “Delivery,” puts a lid on it, and everything else continues as usual. Development teams in such an environment may produce more software, faster and with better quality, but the expected impact on the organization often fails to materialize because the business value of the produced software doesn’t increase correspondingly.

    In this session, we’ll take a closer look at why Agile shouldn’t end with “working software.” The most commonly used Agile frameworks don’t provide much guidance on how to manage risk and ensure the creation of organizational value, so we will draw on insights, tools and techniques from other domains to identify crucial high risk assumptions, test our hypotheses, and measure outcomes. We’ll explore how we can get past the “feature factory” focus and apply the Agile mindset beyond delivery to produce better business outcomes and organizational impact.