Agile Scrum Methodology¶

Estimated time to read: 5 minutes

Agile Scrum isn't just a set of meetings; it's a framework designed to maintain delivery velocity while staying adaptable to changing requirements. This guide breaks down the core roles, ceremonies, and artefacts that turn a chaotic backlog into a potentially shippable product increment.

This diagram represents the Scrum lifecycle¶

erDiagram
  PRODUCT_BACKLOG ||--|{ SPRINT_PLANNING : feeds
  SPRINT_PLANNING ||--|| SPRINT_BACKLOG : generates
  SPRINT_BACKLOG ||--|| DAILY_STANDUP : informs
  SPRINT_BACKLOG ||--|{ DEVELOPMENT : tasks
  DEVELOPMENT ||--|| DAILY_STANDUP : updates
  DEVELOPMENT ||--|| SPRINT_REVIEW : presents
  SPRINT_REVIEW ||--|| SPRINT_RETROSPECTIVE : informs
  SPRINT_RETROSPECTIVE ||--|| PRODUCT_INCREMENT : results
  PRODUCT_INCREMENT ||--|| PRODUCT_BACKLOG : updates

More specifically, the different Scrum stages are:

Product Backlog: The prioritised, living list of user stories and features required for the product. It is owned by the Product Owner and refined continuously.

Sprint Planning: A collaborative session where the Scrum Team defines the work to be completed during the upcoming sprint and establishes the Sprint Goal.

Sprint Backlog: The subset of Product Backlog items selected for the current sprint, along with a plan for delivering the product increment.

Daily Standup: A time-boxed daily event for the Developers to synchronise activities and create a plan for the next 24 hours while identifying impediments.

Development Phase: The period where Developers work on delivering the features defined in the sprint backlog to a "Done" state.

Sprint Review: An informal session at the end of the sprint where the team demonstrates the increment to stakeholders and gathers feedback.

Sprint Retrospective: A dedicated session for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint.

Product Release: The deployment of the potentially shippable increment, though in DevOps environments, this may occur multiple times during a sprint.

Product Increment: The sum of all the Product Backlog items completed during a sprint and the value of all previous increments.

Metrics that you can and probably, should monitor during the Scrum process¶

These metrics can help you monitor the performance, productivity, and quality of your Scrum team and provide insights to guide improvements.

Sprint Burndown Chart: Tracks the remaining work in the sprint backlog over time. It is a critical tool for the team to self-manage and understand their progress toward the Sprint Goal.

Team Velocity: Measures the average amount of work a team completes during a sprint, typically in story points. It is best used for long-term planning, not for comparing teams.

Cumulative Flow Diagram: Visualises the status of tasks over time, revealing bottlenecks and providing insights into the stability of the workflow.

Lead Time: The total time elapsed from the moment a task enters the backlog until it is completed and delivered.

Cycle Time: The time taken to complete a task from the moment work actually commences until it reaches a "Done" state.

Work in Progress (WIP): The number of cards or tasks actively in-flight. Limiting WIP is essential for maintaining a high throughput and reducing context switching.

Escaped Defects: The number of defects identified by users after a release. This is a primary indicator of the health of the team's definition of done.

Team Happiness Index: A qualitative measure of engagement and satisfaction, typically captured during the retrospective to identify morale-based blockers.

How to write stories¶

Story writing is an art on its own and it takes time to perfect. However, a good suggestion is to write user stories from the perspective of the end-user and follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable).

Also, consider adding acceptance criteria to user stories to provide clear expectations for what needs to be done for the story to be considered complete.

How to prioritise the backlog¶

There are several techniques to prioritise the product backlog, including:

MoSCoW: Standing for Must-have, Should-have, Could-have, and Won't-have, this technique categorises items based on their immediate business necessity.

Value vs Effort: A simple quadrant-based evaluation where items are prioritised based on high business value relative to the engineering effort required.

Kano Model: Prioritises features based on how they satisfy user needs, categorised into basic expectations, performance features, and "delighters."

Stack Ranking: A rigorous method of ordering every item in the backlog from 1 to N, ensuring absolute clarity on what is most crucial at any given time.

How to structure backlog¶

To structure your product backlog, follow these steps:

• Break down large features or epics into smaller, manageable user stories.
• Group related user stories under the same feature or epic.
• Use tags or labels to categorise items (e.g., by functionality, priority, or team).
• Continuously refine and update the backlog based on feedback and changing priorities.

How to measure the team's capacity¶

To measure your team's capacity, consider these factors:

Team Availability: Accounting for the total number of members and their actual working hours available during the sprint period.

Historical Velocity: Using the average throughput from previous sprints to provide a realistic baseline for what can be achieved.

Planned Absence and Capacity: Factor in any holidays, training days, or planned absences that will reduce the net capacity of the team.

Quality Outcomes: Assessing the team's track record in delivering code that meets the definition of done without incurring excessive technical debt.

Use these factors to estimate the amount of work your team can take on during a sprint and adjust the sprint backlog accordingly to ensure a sustainable pace and workload.