Poker Planner Laravel Package

Product Decisions This Supports

• Feature evaluation for agile tooling: A planning poker capability fits naturally into sprint-planning workflows (story-point estimation, backlog grooming, team consensus). If your product already serves engineering/scrum teams, this package is a candidate for an in-app estimation feature rather than sending users to a separate SaaS tool.
• Build vs. buy: Leaning "build" only for teams already standardized on Laravel. Off-the-shelf planning poker (PlanningPoker.com, Points, Parabol, etc.) covers the same job with mature UX, integrations, and SSO — this package is a viable "build/embed" option primarily when self-hosting, data residency, or tool consolidation is a priority.
• Internal tools / dogfooding: A pragmatic fit for internal delivery tooling — embedding estimation into an existing Laravel admin/portal, avoiding another vendor and license.
• Roadmap signal (weak): v0.1.3 is a patch release with no changelog detail surfaced in the notes; it confirms active-ish maintenance (release dated 2026-07-05) but provides no product-level intelligence (no new features, no breaking changes documented). Do not treat this release as a maturity or feature milestone.

When to Consider This Package

Consider adopting when:

• You are already on Laravel/PHP and want estimation features without standing up new infrastructure.
• Self-hosting, data controllership, or embedding inside an existing app is a hard requirement.
• You are prototyping an internal estimation tool and can tolerate early-stage APIs.
• Small team scope and modest feature expectations (sessions, voting, reveal, simple scales).

Look elsewhere when:

• You require production-grade maturity: at v0.1.x, expect API churn, thin documentation, and limited guarantees on test coverage, security review, and backwards compatibility. A patch release (0.1.2 → 0.1.3) does not change this.
• You need enterprise capabilities: SSO/SAML, advanced RBAC, audit logs, integrations (Jira, Slack, Azure DevOps), localization, or mobile-native UX.
• Estimation is core to your product's value proposition rather than an internal convenience — a mature SaaS or dedicated package is the lower-risk bet.
• You need vendor support/SLAs (0.x community packages rarely offer these).
• Verification gap to resolve before any decision: the release notes only link to CHANGELOG.md, so confirm what actually changed in v0.1.3 (bugfixes vs. silent behavior changes) and re-run a dependency/security review; a patch bump is not evidence of stability.

How to Pitch It (Stakeholders)

For executives: This is a lightweight, self-hostable planning poker capability for agile estimation, best positioned as an internal-tooling or embedded feature rather than a customer-facing differentiator. The strategic upside is tool consolidation (fewer SaaS licenses, data stays in-house) and reuse of the existing Laravel stack. The caveat is maturity — it is at v0.1.3, so treat it as an experiment, not a platform commitment. Recommend a low-cost spike, not a roadmap dependency.

For engineering: A Laravel-native package that can be dropped into an existing codebase to add estimation sessions, minimizing new infrastructure and language surface area. Trade-off: 0.x versioning means unstable APIs, likely sparse docs/tests, and possible breaking changes on minor bumps — pin versions, wrap the integration behind an internal interface, and budget maintenance. This release (v0.1.3) is a patch with no substantive changelog detail; validate the diff and dependency posture before integrating.