In a nutshell...

  1. Requirements go to the Product Owner
  2. Product Owner prioritises the Product Backlog
  3. Scrum Team estimate and design sprint
  4. Sprint Starts
    1. Development team complete work in the sprint and test
    2. QA Team test new features via stories
  5. Sprint demo and review
  6. Rince and repeat until...
  7. We have a release candidate and deploy.

Pre Development

Define Epics

Before the project can move towards development, we need to define what we are building and when it will be surfaced to the public.

The Product Owner (PO) is responsible for defining the Product Backlog, items will be selected from the product backlog for the next sprint or following sprints.

On a new project or new phase, we'll define relative estimates for epics to determine priority order what is likely to fit within a defined number of sprints.

Steps

Objective

Have a product backlog with DOR sprint ready epics that are in priority order to pick up from the top down for the next development cycle.

Development

Pre Sprint (Backlog Refinement)

Before a sprint kicks off, the Product Owner works with the Scrum Master (SM) to prioritise and refine the product backlog and select the items that fit within the planned sprint.

This is a list of stories that belong to the epics defined in the Pre Development stage.

Before the pre-planning meetings can happen, the stories must be DoR.

Story tickets ready (DoR - 'Definition of Ready')

Stories need to include the following to be considered ready for development;

  • A story for each user journey
  • User Stories written
  • Acceptance Criteria written from user stories
  • Test Scripts written from user stories and acceptance criteria
  • UX/UI Wireframes written from the user stories
  • Designs
  • Solution Architect outlines tech solution

Pre Sprint (Backlog Refinement - Pre-planning sessions)

A pre-planning meeting allows the Product Owner and the Scrum Master to work with the development team to refine the product backlog and create tech 'tasks' prior to the sprint starting. (more info on tasks and points)

The above example is to implement Displays Ads and has two separate user journeys defined as stories, one for the standard user experience, another for premium users. We then have six technical tasks to complete those stories. The first task is backend work, the following are UI related.

Sprint Start

To start a sprint, all stories and tasks must be ready with their estimates.

  • Sprint planning meeting
    • clarify what is being built and accuracy of story point estimates, including points for testing
    • are there any dependencies that will block tasks
    • order the sprint backlog for the more efficient delivery
  • Work begins - sprint board “Only My Issues” - do items in order as they appear in the sprint board
  • Limit WIP tasks, be a closer
  • Daily Standup - time box to 5 mins, "what I did yesterday, what I'm doing today, surface my blockers"
  • Sprint Backlog Refinement sessions (daily status review)

Completing tasks (DOD - Definition of Done)

  • Stories - since stories are the testable component, they need to have;
    • completed development, 
    • have been approved by design 
    • and passed QA before they are moved to 'Done'
  • Tasks - technical tasks can be moved to 'Done' once the work is complete. This will allow us to see progress of workload on the burndown chart.

Closing a sprint

  • Ensure all tasks that are complete have been moved to Done as per DoD.
  • Can stories be split?
  • Sprint build or staging ready for demo

Post Sprint

  • Since the version is already defined in JIRA, release notes can be automatically produced on completion of the sprint.
  • Determine velocity - Once a team has completed three or more sprints, we can average the points on tasks marked as 'Done' over those sprints to get a velocity. We can then use that number to determine what can be achieved in the following sprints.
  • Retrospective - A 'retro' is the opportunity for the whole team to reflect on our approach and make suggestions to further evolve the way we work. This allow the team to always be progressing forward and making work easier and therefore more efficient.
  • Go to the Winchester for a pint