Team Assessment

This assessment looks at the operating model underneath your team: how it is composed, how clearly roles are held, how work is made visible, how reliably it delivers, and whether it actually improves. Those five areas compound. A team with unclear roles will struggle to make delivery predictable no matter how good its tooling is. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1 to 20: Struggling. The team is a group of people assigned to the same work rather than a team. Roles are unclear, work is invisible outside individual heads, and delivery depends on who happens to be paying attention that week.

21 to 40: Developing. Some structure exists but it does not hold under pressure. Events happen inconsistently, the board is out of date more often than not, and improvement conversations end without anything changing.

41 to 60: Norming. The team has a working rhythm and the basics are real. The next gains come from tightening role clarity, making delivery predictable enough to plan around, and closing the loop on the improvements the team already identifies.

61 to 80: Performing. The operating model works. Roles are clear, work is visible, delivery lands close to commitment, and retrospectives produce change. Focus on flow, release frequency, and the depth of ready work.

81 to 100: Thriving. This is a team other teams should learn from. It is composed well, it self corrects without prompting, and its commitments are believed because they are met. Protect the conditions that got you here.

Team Size

What is the number of team members including the Scrum Master, Product Owner, and Tech Lead?

Why it matters: Size determines how much of everything else is even possible. Six to nine people is the range where a team can hold a real conversation, cover the skills needed to finish work without waiting on outsiders, and still know what everyone is doing. Below six, the team usually lacks a discipline and becomes dependent on borrowed capacity. Above twelve, communication paths multiply, decisions slow, and a subgroup starts making calls on everyone’s behalf, which is why the largest band carries a penalty.

To improve your score: If you are at thirteen or more, examine whether you are looking at two teams sharing a backlog. Split along the work rather than along reporting lines, and give each team its own backlog, its own Product Owner attention, and its own events. If you are under six, confirm you have counted the Scrum Master, Product Owner, and Tech Lead, then close the biggest skill gap with a dedicated member rather than a part time contributor split across three teams.

Time Zone Coverage

How many time zones are represented across the team’s locations?

Why it matters: Every additional time zone adds a delay to every question the team needs answered. One or two zones means a blocker raised in the morning gets resolved the same day. Five or more means the team runs on handoffs, decisions wait a full day for a reply, and the people furthest from the center of gravity gradually stop asking and start guessing.

To improve your score: You often cannot change the map, so change how the team works across it. Cluster the team into the fewest zones you can when staffing decisions come up. Define a daily overlap window that everyone protects and put the decision heavy events inside it. For everything else, work asynchronously on purpose: written decisions with a stated deadline, recorded demos, and a rule that no one waits idle on an answer that could be documented.

Time Zone Span

What is the largest time zone span, in hours, represented within the team?

Why it matters: The count of zones tells you how fragmented the team is, the span tells you whether a shared working hour exists at all. Within three hours, the team can meet at a reasonable time for everyone. Beyond seven, somebody is always working outside their normal day, and if that burden always falls on the same location, that location quietly disengages.

To improve your score: Find the true overlap and publish it as core hours. Rotate the meeting times that fall outside a reasonable day so the cost is shared rather than assigned. Cut the number of synchronous events at the edges of the span and replace them with written updates. Where a wide span is permanent, give each cluster enough autonomy to keep moving without a daily approval from the other end of the world.

Tooling Footprint

What software does the team use?

Why it matters: This question checks that the team has actual tooling behind its work rather than tracking commitments in chat threads and personal notes. A team with a work tracking system and a knowledge base has somewhere for decisions to live, which is what lets a new member get productive and lets a stakeholder self serve instead of interrupting the team. Having none of these is the real risk here.

To improve your score: Make sure the team has at least one system of record for work and one for documentation, and that both are actually used rather than nominally licensed. Then look at the opposite problem: if work is spread across several trackers, pick the primary one and consolidate, because a second tracker guarantees a second version of the truth. Whatever you choose, ensure every member has access and knows where a decision is supposed to be recorded.

Team Charter

Does your team have a documented team charter or working agreement?

Why it matters: A charter is where a team writes down how it wants to work before it is under pressure: core hours, response expectations, how decisions get made, what done means, and how disagreement is handled. Teams without one still have norms, they just have unwritten ones that nobody agreed to and that newcomers have to learn by making mistakes. The cost shows up as repeated friction over things the team believes it already settled.

To improve your score: Draft it in a single ninety minute working session with the whole team and keep it to one page. Cover working hours and overlap, communication channels and expected response times, how the team makes a decision when it disagrees, and the behaviors it will not accept. Review it in a retrospective every quarter and when someone joins, and edit it rather than defending it, because a charter nobody references is only slightly better than none.

Scrum Master Role

Is the Scrum Master / facilitator role clearly filled?

Why it matters: Somebody has to own the health of how the team works, or it defaults to whoever is loudest or most senior. A clearly filled facilitator role means events start and end with a purpose, blockers get escalated rather than tolerated, and the team’s improvement work has an owner. When it is informal, facilitation gets dropped the moment delivery pressure rises, which is exactly when it is needed most.

To improve your score: Name the person and the expectation, not just the title. Define what they own: facilitating the team’s events, removing blockers the team cannot clear alone, protecting the team from unplanned intake, and tracking improvement actions to closure. If the role is shared or rotating, keep the rotation long enough to build competence and give the person real time for it rather than adding it on top of a full delivery load.

Product Owner Role

How clearly defined and engaged is your Product Owner role?

Why it matters: The Product Owner is the team’s answer to what matters most and what done looks like. When the role is defined but disengaged, the backlog ages, questions raised during a sprint sit unanswered, and engineers make product decisions by default. When the role is unclear, priorities arrive from several directions at once and the team spends its energy arbitrating instead of building.

To improve your score: Give the role a single name and a single decision right over the backlog order. Agree a response time for questions raised during the sprint and treat a missed one as a blocker worth escalating. Get the Product Owner into refinement and planning consistently, because attendance is the cheapest way to prevent a sprint of wrong assumptions. If the person is spread across several teams, that is a capacity problem to raise rather than a personal failing.

Stakeholder Clarity

How clear and engaged are your key business stakeholders?

Why it matters: Unclear stakeholders are how teams end up building the right thing for the wrong person. When nobody can name who the work is for, feedback arrives late and from whoever happens to see the demo, and priorities get reopened after the work is done. Identified but inconsistent engagement produces a similar failure with a slower fuse: silence during the sprint, then strong opinions at the end.

To improve your score: Write down the small number of people whose sign off actually matters, with what each one cares about and what decision each one owns. Get them to the sprint review on a standing invitation rather than an ad hoc one, and give them one channel for requests that routes through the Product Owner. Where a stakeholder never engages, take that as data about priority and confirm it explicitly rather than assuming.

Role Understanding

How well do individual team members understand their roles and responsibilities?

Why it matters: Role confusion is expensive in a quiet way. Two people do the same work, or nobody does it because each assumed the other had it. It also shows up in decision making, where people escalate things they are allowed to decide and decide things they should have raised. Teams that report overlap or confusion usually have grown or reorganized without ever restating who owns what.

To improve your score: Run a short responsibility mapping session. List the ten activities the team actually does, from refining work to responding to production issues, and agree who owns each one and who needs to be consulted. Write the result into the team charter. Revisit it whenever someone joins or leaves, because that is when the invisible assumptions break.

Communication Cadence

How would you describe your team’s communication cadence and responsiveness?

Why it matters: Responsiveness is the tax rate on every dependency inside the team. When answers come back in minutes, work keeps moving. When they take a day, people either sit blocked or make an assumption and carry the risk forward. Inconsistent communication is often worse than slow communication, because the team cannot plan around it and starts routing everything through the one or two people who always reply.

To improve your score: Set an explicit expectation for each channel, such as chat within the working day and a same day answer during core hours, and put it in the charter. Move status out of meetings and into the board so synchronous time is spent on blockers and decisions. Make raising a blocker a normal act rather than an admission, and check in the retrospective how long the last few blockers actually took to clear.

Team Board Maturity

How mature is your team’s use of a team board or visual management tool?

Why it matters: The board is the team’s shared picture of reality. Updated daily, it makes standup a conversation about flow instead of a round of verbal reports, and it lets anyone see where work is stuck without asking. Updated occasionally, it becomes a source of misinformation that people learn to distrust, and the team drifts back to asking individuals what is really happening.

To improve your score: Agree that the board is updated as work moves rather than before a meeting, and hold the standup off the board so gaps are visible immediately. Keep the columns matched to how work actually flows, including any review or waiting state the team pretends does not exist. Remove statuses nobody uses. If items sit in one column for days, that is the conversation, and the board only earns trust once the team acts on what it shows.

Work Visibility

How visible is the team’s work to everyone on the team?

Why it matters: Visibility is what allows a team to help itself. When everyone can see what is in flight, people pick up the item that unblocks someone else, spot duplicated effort, and notice when one person is buried. When work is visible only on request, the team loses the ability to self organize and coordination moves to the manager, which slows everything and makes the team dependent on one person’s attention.

To improve your score: Get all work onto one board, including the interrupts, support rotations, and side commitments that usually live off it, because hidden work is what makes capacity conversations feel dishonest. Make in progress items visible by owner so imbalance is obvious. Then use the board in every team conversation, since visibility that nobody looks at is just data entry.

Tooling Support for Collaboration

How well does your team’s tooling support real-time visibility and collaboration?

Why it matters: Tooling either removes friction or adds it, and there is not much middle ground. When the tools fit, updating work is a few seconds and everyone sees it immediately. When they do not, people batch their updates, keep a private list that is more accurate than the shared one, and the team’s real state lives somewhere the tools cannot see. That gap is where most surprises come from.

To improve your score: Ask the team where the friction actually is, since it is usually two or three specific things: too many required fields, a workflow with statuses nobody believes, permissions that block updates, or notifications so noisy people stopped reading them. Fix those rather than replacing the platform. Connect the tools people already live in so an update in one place is visible in the other, and cut any field that no decision depends on.

Relationship Building

How often does your team engage in relationship-building or team bonding activities?

Why it matters: Teams that never spend unstructured time together default to transactional communication, and transactional teams avoid the harder conversations: disagreeing with a design, admitting a task is stuck, saying an estimate is unrealistic. This is most acute on distributed teams, where every interaction is scheduled and nobody bumps into anyone. The cost is not morale, it is the information that never gets raised.

To improve your score: Make it regular and small rather than occasional and elaborate. A short open agenda call each week, a rotating demo of something someone learned, or the first few minutes of an existing event held for something other than status will do more than an annual offsite. Vary the format so it does not always favor the same personalities, and keep attendance genuinely optional so it stays a benefit rather than another meeting.

Sprint Cadence Consistency

How consistent is your team’s sprint or iteration cadence?

Why it matters: A fixed cadence is what makes everything else measurable. Same length every time means velocity is comparable, planning is a habit rather than an event, and stakeholders know when to expect a demo. When sprints stretch to fit unfinished work or get skipped under pressure, the team loses its only stable reference point and every forecast becomes a fresh negotiation.

To improve your score: Pick a length, usually one or two weeks, and hold it even when the sprint goes badly. Never extend a sprint to finish work, because carrying the item into the next sprint is honest and extending hides the miss. Put the full event schedule on recurring invitations for the next several months. If a hardening or release period keeps breaking the cadence, plan it as its own iteration rather than letting it distort the others.

Delivery Predictability

How predictable is your team’s delivery (commitment vs. completion rate)?

Why it matters: Predictability is what turns a team’s word into a plan the business can use. A team that reliably completes most of what it commits to earns the right to be left alone, while a team that completes half gets managed more closely, which makes it slower still. Not tracking commitment against completion at all is the weakest position, because the team cannot tell whether it is improving.

To improve your score: Start measuring it if you are not. Record what was committed and what closed each sprint, and look at the last six as a set. Then attack the two usual causes: overcommitting because capacity was assumed rather than calculated, and unplanned work arriving after planning. Commit to less than you think you can finish for two sprints and let the team feel what finishing everything is like, then grow the commitment from evidence.

Release Frequency

How frequently does your team release or deploy work to production/customers?

Why it matters: Release frequency is where the team finds out whether its work was right. Frequent small releases mean small blast radius, fast feedback, and problems that are easy to trace to a change. Monthly or infrequent releases batch risk, so every deployment becomes an event that needs coordination and a rollback plan, and the team learns slowly because value sits finished but undelivered.

To improve your score: Look at what actually blocks a release rather than assuming the answer is more automation, though it often is. Common causes are manual regression testing, a change approval process built for a different era, and environments that do not match production. Pick the single largest one and invest there. Decouple deploy from release using feature flags so code can ship continuously while exposure is controlled by the business.

Backlog Readiness

How well-refined and ready is your product backlog?

Why it matters: A refined backlog is what makes planning a selection conversation instead of a design session. When the top items are ready one or two sprints ahead, the team starts with shared understanding and finishes what it starts. When refinement happens at the last minute, work begins with open questions, and the answers arrive mid sprint as scope the team never planned for.

To improve your score: Put refinement on the calendar as a standing session with the Product Owner present and the backlog on screen. Target roughly two sprints of ready work, defined by an agreed standard: clear description, testable acceptance criteria, known dependencies, and a size the team is comfortable with. End each session by looking at the top of the backlog and asking whether the team could start any of it tomorrow without another meeting.

WIP and Flow

How well does your team manage work in progress (WIP) and flow?

Why it matters: Too much work in progress is the most common reason teams feel busy and deliver slowly. Every extra item in flight adds context switching, lengthens cycle time for everything else, and pushes finishing to the end of the sprint. Bottlenecks are usually at a handoff such as review or testing, and without a limit the team keeps starting new work rather than clearing the queue.

To improve your score: Set a WIP limit for the team, start it near the number of people, and treat hitting the limit as a signal to help finish rather than an inconvenience to override. Make the constrained step visible on the board and agree a response time for review. Establish the norm that finishing existing work beats starting new work, and check the effect through cycle time rather than through how busy the team feels.

Retrospective Regularity

How regularly does your team hold retrospectives?

Why it matters: The retrospective is the only event whose purpose is the team itself, which is exactly why it is the first one cancelled when delivery pressure rises. Skipping it does not save time, it defers the cost. Problems the team could have named early become the reasons a quarter went badly, and people stop raising issues at all once they learn there is no forum for them.

To improve your score: Hold it every sprint without exception and protect the time on the calendar. If attendance is the problem, shorten it rather than skipping it, because forty five focused minutes beats a cancelled ninety. Rotate facilitation so it does not become one person’s meeting, and vary the format so the team is not answering the same three prompts for the twentieth time.

Retrospective Follow Through

How well are retrospective action items tracked and closed out?

Why it matters: Follow through is what separates a retrospective from a complaint session. When actions are named and closed, the team sees that raising something changes it, and participation deepens. When actions are discussed and forgotten, the same issues reappear every few sprints, people stop offering the difficult observations, and the event degrades into a formality everyone attends and nobody values.

To improve your score: Leave every retrospective with at most two actions, each with a named owner and a date, and put them in the same backlog as the delivery work so they compete for real capacity. Open the next retrospective by reviewing them before anything else. If an action keeps rolling over, either it is too large to finish inside a sprint or it needs a decision the team cannot make alone, and both of those are worth saying out loud.

Raising Process Friction

Does your team have a mechanism to raise and resolve process friction outside of retrospectives?

Why it matters: A team that can only surface problems on a two week cycle carries every issue until the next scheduled slot, by which time the details are gone and the cost is already paid. An always open mechanism means a broken environment, an unclear handoff, or a painful approval step gets named the day it happens. It also gives quieter members a route that does not require speaking up in a group.

To improve your score: Create one obvious place to raise friction, such as a channel or a lane on the board, and make it visible rather than private so the team can see the pattern. Give the Scrum Master or facilitator explicit ownership of triaging what lands there. Close the loop publicly on what was fixed, because visible resolution is what convinces people the mechanism is real and not a suggestion box.

Process Experimentation

How often does your team experiment with process improvements?

Why it matters: Teams that never experiment optimize for the way they already work, which caps them at their current performance. Experimentation is how a team finds out whether pairing shortens review time or whether a smaller WIP limit actually improves cycle time, instead of debating it. The teams that improve fastest are usually not the ones with the best ideas, they are the ones that try more of them and keep what works.

To improve your score: Run one experiment per sprint with a stated hypothesis, a duration, and a measure agreed in advance. Keep it small enough that the team can reverse it. At the end, look at the measure and decide to adopt, adjust, or drop it, and record the outcome so the same idea is not relitigated in three months. Treat a failed experiment as a result rather than a mistake, since that is what makes the next one possible.

Applying Lessons Learned

How well does your team incorporate lessons learned into future work?

Why it matters: Lessons that live only in the memory of whoever was present leave when that person does. The teams that compound improvement are the ones that turn a lesson into something structural: a checklist item, an addition to the definition of done, a change to the template, a new step in the release process. Everything else fades within a few sprints and the same incident happens again with different names.

To improve your score: When the team learns something worth keeping, ask where it should live so nobody has to remember it. Update the definition of done, the working agreement, the story template, or the runbook in the same session rather than promising to do it later. Review those artifacts each quarter and remove what no longer applies, because a document that only grows stops being read.