Scrum uses specific artifacts such as the product backlog, sprint backlog, and the increment. The product backlog is a prioritized list of project requirements with estimated times to turn them into completed product functionalities. Sprint backlog is a list of tasks identified by the Scrum team to be completed during the current sprint. An increment is a sum of all the product backlog items completed during a sprint. In contrast, other Agile frameworks may not have these specific roles or may define them differently. For example, Kanban does not strictly require the same artifact structure, instead focusing on visual representations of work and workflows.

Transparency is a vital principle in Scrum, where progress is visually tracked via Scrum boards, and changes are made regularly and conspicuously. It demands everyone to have a unified understanding of what's being done. In comparison, while transparency is always a goal within an Agile approach, other frameworks may not enforce it as strictly as Scrum. For instance, Kanban boards indeed provide visual cues, but it does not plainly insist on the same level of transparency as Scrum.

Scrum methodology requires routine check-in points and reviews, presenting a high level of formal reporting, such as Burndown charts and velocity tracking. However, other Agile methodologies may not emphasize the same reporting structure. For example, XP relies on constant feedback and less on formal reports, while Crystal prioritizes team communication over formal record-keeping.

In the Scrum framework, there are three defined roles: The Product Owner, the Scrum Master, and the Scrum Team. The Product Owner is responsible for representing stakeholders' interests and optimizing the value of the team's work. The Scrum Master handles the Scrum framework's implementation, resolves obstacles, and mentors the team. The Scrum Team self-organizes to deliver the 'Done' increments. In contrast, other Agile frameworks like Kanban or Lean do not emphasise defined roles, preferring a more collaborative and fluid approach where every team member can handle multiple responsibilities.

Scrum has specific ceremonies or events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events create regularity and help teams align on what’s been accomplished and what’s next. They also promote transparency, inspection, and adaptation. Other Agile frameworks, like Kanban, lack such distinct or time-boxed events but focus more on continual delivery and limiting work in progress.

Scrum operates in fixed-duration iterations called Sprints - typically lasting two weeks to one month. Work items are pulled into a Sprint to focus efforts on a manageable amount of work. The aim is to deliver 'Done' increment(s) by the Sprint end. Other Agile frameworks like Kanban do not necessarily work in fixed iterations. Instead, they focus on continuous flow, with work items pulled into 'InProgress' as soon as the team has capacity.

Scrum requires a single source of requirements prioritized by the Product Owner known as the Product Backlog. Each item (Backlog Item or User Story) in the product backlog adds incremental value to the product. This contrasts other frameworks like Feature-Driven Development (FDD), which maintains features list rather than a prioritized backlog.

Scrum insists on a clear 'Definition of Done (DoD)' for all backlog items. The 'DoD' is a shared understanding among the team about what 'Done' means for a backlog item or an increment. It guarantees the quality, completeness, and potentially shippable state of the increment. Other Agile methodologies, while promoting done work, might not strictly define or standardize the criteria, affecting the consistency, transparency, and quality of the deliverables.

While Scrum and Kanban are both Agile methodologies, their workflows significantly differ. Scrum has specific, time-boxed sprints typically lasting from one to four weeks in duration. Scrum teams aim to release a potentially shippable increment of work at the end of each sprint. Conversely, Kanban uses a continuous flow system where work items move through various stages from 'to-do' to 'done' at their own pace. This allows for more flexibility in responding to changes or issues during the development process.

The Lean Startup methodology emphasises on the elimination of waste — 'waste' being anything that doesn't deliver value to the customer. The goal is to deliver a minimal viable product (MVP) fast to test the market and iteratively improve based on customer feedback. However, Scrum focuses less on waste and more on maximizing the value delivered in each sprint through committed backlog items. It does not specifically address the identification and reduction of waste like Lean Startup.

Scrum and Extreme Programming (XP) are both Agile methodologies, yet they handle engineering practices differently. While Scrum doesn't prescribe any specific technical practices, focusing more on management and collaboration aspects, XP prescribes specific engineering practices like Test-Driven Development (TDD), Continuous Integration, Pair Programming, etc., believing that high-quality code is the best foundation for responding to change.

Scrum utilizes a simple, team-based framework suitable for single teams or small organizations. The framework doesn’t inherently support scaling across multiple teams or larger organizations. In contrast, Scaled Agile Framework (SAFe) extends Scrum (and other Agile principles) to provide a structure that's more suitable for coordinating work across multiple teams or larger organizations, taking into account additional layers of governance and planning.

Scrum and Dynamic Systems Development Method (DSDM) handle the prioritization of work differently. In Scrum, the product owner is mainly responsible for prioritizing the product backlog items, taking into account business value, dependencies, risk, and other factors. On the other hand, DSDM uses a MoSCoW prioritization method (Must have, Should have, Could have, Won’t have) that the whole team collaboratively works on to prioritize the project’s requirements.