Team Expertise
Team Expertise is the deliberate use of the Scrum Team’s collective skills, experience, and domain knowledge to evaluate options, estimate work, identify risks, and make decisions. It is applied through collaborative discussions and techniques to produce well-grounded plans, forecasts, and improvements across SBOK processes.
Key Points
- Uses the cross-functional knowledge of the Scrum Team to inform estimates, designs, and decisions.
- Applied throughout Scrum: backlog refinement, sprint planning, risk assessment, reviews, and retrospectives.
- Works best when combined with empirical data such as velocity, defects, throughput, and spike results.
- Facilitated by the Scrum Master to encourage equal participation and reduce bias.
- Complements structured techniques like Planning Poker, T-shirt sizing, and risk workshops.
- Produces transparent, documented rationale captured in Scrum artifacts and team working agreements.
Purpose of Analysis
Team Expertise is used to analyze uncertain or complex work, choose practical approaches, and arrive at reliable estimates and commitments. It helps uncover assumptions, dependencies, and risks so the team can adapt the product backlog and plan sprints realistically.
This technique is especially useful when requirements are evolving, technology is novel, quality attributes are critical, or integration and external dependencies are high.
Method Steps
- Set the context: clarify the product goal, relevant epics or user stories, acceptance criteria, and constraints.
- Convene the right people: Developers, Product Owner, and when helpful, knowledgeable stakeholders.
- Elicit perspectives: use time-boxed discussions, Planning Poker, brainstorming, and risk prompts to surface knowledge.
- Triangulate with data: compare opinions against past velocity, cycle time, defect trends, and spike findings.
- Converge and record: reach a consensus on sizing, approach, risks, and assumptions; document in the backlog and logs.
- Validate with stakeholders: confirm understanding, dependencies, and acceptance criteria.
- Inspect and adapt: review outcomes in the Sprint Review and Retrospective to refine future use of expertise.
Inputs Needed
- Product vision, product goal, and prioritized product backlog items with acceptance criteria.
- Definition of Ready and Definition of Done.
- Historical metrics: velocity, throughput, lead time, defect trends, and capacity data.
- Architecture or compliance constraints and organizational standards.
- Risk register, impediment log, and assumptions.
- Results from spikes, prototypes, or proof-of-concept experiments.
- Stakeholder feedback and non-functional requirements.
Outputs Produced
- Story sizes and time-bound forecasts for sprint planning and release planning.
- Refined or split backlog items with clearer acceptance criteria and test ideas.
- Identified risks, updated risk responses, and noted dependencies.
- Documented technical approach notes and decisions.
- Updates to Definition of Done, quality checks, or working agreements.
- Capacity adjustments, impediment removal actions, and updated assumptions.
Interpretation Tips
- Treat expert opinion as data to be tested with small experiments and incremental delivery.
- Favor consensus and transparency; capture the rationale for later review.
- Guard against anchoring and dominance by using silent estimation or anonymous first votes.
- Invite outside specialists for input, but keep decisions within the Scrum Team.
- Revisit estimates and decisions when new information appears or after each sprint.
Example
A team refines an epic that adds performance improvements. Using their combined experience, they split the epic into measurable user stories, outline a load-testing approach, and estimate with Planning Poker.
They identify a risk around third-party limits, add a spike to validate assumptions, and update the Definition of Done to include performance tests. These decisions shape the sprint forecast and risk responses.
Pitfalls
- Over-reliance on a single senior expert, reducing diverse perspectives.
- Ignoring empirical metrics and past performance when estimating.
- Groupthink or anchoring that skews estimates and decisions.
- Analysis paralysis caused by open-ended discussions without timeboxes.
- Failure to document outcomes, leading to rework and lost context.
- Outdated expertise applied to new technology without validation.
PMP/SCRUM Example Question
During backlog refinement for a complex integration story, the team is unsure about sizing and risks. What is the best application of Team Expertise?
- Ask an external architect to choose the design and accept it without team discussion.
- Use the team’s cross-functional experience to discuss risks, split the story, run a quick spike if needed, and estimate with Planning Poker.
- Have the most senior developer decide the estimate and technical approach.
- Ask the Scrum Master to set the approach to keep the meeting on time.
Correct Answer: B — Use the team’s cross-functional experience to discuss risks, split the story, run a quick spike if needed, and estimate with Planning Poker.
Explanation: Team Expertise is a collaborative technique that leverages the entire Scrum Team’s knowledge, supported by data and experiments. Options A, C, and D bypass team collaboration or assign decisions to a single person.
