Velocity is a crucial Scrum metric that gauges the amount of work a team can accomplish during a sprint. It is calculated by summing all the story points assigned to each user story completed by the end of the Sprint. It measures output, not the outcome.

In Sprint Planning, the team’s velocity can influence the number of product backlog items to tackle. As a result, we can estimate both the workload and the delivery date. At the conclusion of the Sprint, the actual velocity will inform the next calculation.

Democratizing User Story Creation in Agile Teams

While the Product Owner is ultimately responsible for the existence and quality of the Product Backlog, the process of writing user stories should be collaborative. This collaborative approach allows the team to leverage diverse perspectives while maintaining clear accountability through the product owner's role. Key principles:

1. Shared Ownership of Story Creation
   • Every team member is encouraged to contribute user stories.
   • Developers, testers, and UX designers frequently offer important insights into technical aspects and usability.
   • Cross-collaboration among cross-functional teams results in more thorough and well-rounded requirements.
2. Discussion Over Authorship
   The real value comes from:
   • Collaborative refinement sessions (backlog grooming)<./li>
   • Multi-perspective input during story mapping.
   • Collective understanding of customer needs.
3. Product Owner's Curatorial Role
   The PO ensures:
   • Stories align with product vision and strategy.
   • Acceptance criteria are clear and testable.
   • Business value is properly articulated.
4. Benefits of Distributed Story Writing
   • Leverages diverse expertise across the team<./li>
   • Creates shared ownership of deliverables.
   • Surfaces hidden assumptions earlier.
   • Improves implementation feasibility.

Remember: A user story's quality isn't determined by who wrote it, but by the richness of conversations it generates and the shared understanding it creates.

In the Scrum Guide 2020, Scrum teams are self-organising and cross-functional. Scrum teams are self-managing, meaning they internally decide who does what, when, and how. They are also cross-functional, meaning the members possess all the skills necessary to create value each Sprint.

Sprint Duration & Agile Delivery Rules

1. A Sprint's maximum duration is one month, but it can be shorter, typically lasting one to four weeks, with the average being two weeks.
   • Rationale: Short feedback loops enable empiricism
   • A Sprint duration depends on the organization and their deliverables as this may be elongated if the product (hardware & software) or the organization (volunteer-based deliverables) requires adjustments!
2. The Agile Manifesto allows for up to two months between each delivery of customer value.
3. Critical Distinctions
   

   Concept	Scrum Rule	Agile Alignment
   Sprint Length	≤1 month	(Scrum compliance)
   Increment Completion	Potentially releasable every Sprint	Supports frequent delivery
   Actual Releases	No strict rule	Should align with Agile Principle #3 ("frequent delivery")

4. Implementation Checklist
   • Keep Sprints ≤1 month (Scrum compliance)
   • Release at least every 2 months (Agile compliance)
   • For infrequent releases:
     • Still deliver Done increments every Sprint
     • Use feature flags/dark launches to decouple deployment from release
5. Consequences of Violation
   • >1-month "Sprints" → Not Scrum (lose empiricism)
   • >2-month releases → Not Agile (violates customer focus)

   Even with 1-month Sprints, accumulating unreleased increments risks becoming "Agile in name only"