HKSM

Curated knowledge and artifacts from earlier Scrum projects or releases, such as lessons learned, metrics, checklists, and templates, that inform a new project. It is gathered from retrospectives and repositories and used during initiation, planning, estimation, risk identification, and quality planning.

Key Points

• Serves as an input to Initiate and Plan and Estimate processes in the SBOK, including Create Project Vision, Develop Epics, Create Prioritized Product Backlog, Conduct Release Planning, Estimate User Stories, and Identify Risks.
• Primarily sourced from outputs of Retrospect Sprint, Retrospect Release, and Retrospect Project, plus organizational knowledge bases.
• Includes both quantitative data (velocity, defect trends, cycle time) and qualitative insights (retrospective notes, working agreements).
• Improves forecasting, reduces risk, and accelerates setup by reusing proven practices and templates.
• Must be validated for relevance and context before use to avoid misleading assumptions.
• Should be maintained as a living repository that is updated after each sprint, release, and project closure.

Purpose

Previous Project Information provides evidence-based guidance when starting or planning a Scrum project. It helps the Product Owner, Scrum Master, and Scrum Team make realistic decisions on scope, estimates, risks, and quality standards.

By leveraging what worked and what failed in comparable efforts, teams reduce uncertainty and set practical expectations for value delivery and timelines.

Key Terms & Clauses

• Lessons learned and retrospective notes - actionable insights captured at sprint, release, and project levels.
• Velocity history - past throughput that can inform initial capacity assumptions and release planning.
• Definition of Done and Definition of Ready - prior checklists that can seed or refine current working agreements.
• Risk register and issue log - known pitfalls, triggers, and effective responses from similar products or domains.
• Stakeholder register and communication patterns - who mattered, how they engaged, and what frequencies worked.
• Templates and checklists - story templates, acceptance criteria patterns, estimation scales, and compliance lists.
• Quality metrics - defect density, escaped defects, test coverage, and lead time trends from previous releases.

How to Develop/Evaluate

Collect:

• Pull retrospective summaries, release reports, and final project reviews from the knowledge base or wiki.
• Extract metrics from tooling such as ALM boards, CI/CD, and test management systems.
• Gather working agreements, DoD/DoR, risk logs, and stakeholder maps from similar projects.

Evaluate:

• Check recency and relevance - prioritize items from projects with similar domain, technology, and team size.
• Rate evidence strength - prefer measured data and repeated patterns over isolated anecdotes.
• Identify context limits - document assumptions so users understand when a tip or metric applies.
• Sanitize sensitive data - anonymize people and remove confidential details while keeping the learning intact.

How to Use

• Initiate - use insights as input to Create Project Vision and Develop Epics to set realistic goals and scope slices.
• Backlog - apply past acceptance criteria patterns and DoR to improve user stories in the Prioritized Product Backlog.
• Estimation - seed initial velocity ranges and estimation scales during Estimate User Stories and Create Sprint Backlog.
• Release planning - reference historical throughput and defect trends in Conduct Release Planning to shape increments.
• Risk management - scan prior risk registers during Identify Risks to anticipate threats and pre-plan responses.
• Quality - adopt or adapt earlier Definition of Done and checklists to maintain consistent quality practices.

Example Snippet

Project X - Mobile Payments v2:

• Velocity stabilized at 28-32 points by sprint 4; defects dropped 35 percent after adding API contract tests.
• Top risks: third-party API rate limits, app store approval delays; effective responses included early sandbox testing and parallel submission dry-run.
• DoD addendum: performance test at 1.5x expected load and accessibility checks on all UI stories.
• Template: user story with Gherkin acceptance criteria improved clarification during refinement.

Risks & Tips

• Risk of false precision - treat historical velocity as a range, not a promise; recalibrate after first sprint.
• Context mismatch - avoid reusing practices from dissimilar domains or architectures without piloting.
• Anchoring bias - do not let one past metric dominate current decisions; gather multiple data points.
• Stale guidance - set a review cadence to retire outdated practices and refresh with new learnings.
• Tip - link each reused practice to a specific SBOK process and an owner to monitor effectiveness.
• Tip - convert key insights into backlog improvement tasks so they are visible and actionable.

PMP/SCRUM Example Question

A Scrum Master is facilitating release planning for a new product. The organization has a repository of lessons learned, velocity histories, and prior Definitions of Done from similar teams. What is the best use of this Previous Project Information?

1. Adopt all past practices and metrics as mandatory constraints for the new team.
2. Use it as input to planning and estimation after validating relevance and context differences.
3. Ignore it because each Scrum project is unique and should start from a blank slate.
4. Use it to set individual performance targets for developers to ensure higher velocity.

Correct Answer: B — Use it as input to planning and estimation after validating relevance and context differences.

Explanation: Previous Project Information informs but does not dictate decisions. Teams should assess relevance and then apply insights to release planning, estimation, risks, and quality agreements.