In a nutshell...
- Product Owner prioritises the Product Backlog
- Scrum Team estimate and design sprint
- Sprint Starts
- Development team complete work in the sprint and test
- Sprint demo and review
- Rince and repeat until...
- We have a release candidate and deploy.
Before the project can move towards development, we need to define what we are building and when it will be surfaced to the public.
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.
- Feature list defined as epics including relative business value (more info on epics)
- Relative estimates added to epics with developers (more info on points)
- Epics added into JIRA and backlog (if done externally)
- Set planned release dates with versions based off predicted velocity and available sprints (more details on velocity)
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.
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.
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
- Solution Architect outlines tech solution
Pre Sprint (Backlog Refinement - Pre-planning sessions)
. (more info on tasks and points)
The above 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.
To start a sprint, .
- 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
- 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)
- - 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'
- - 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.
- Sprint build or staging ready for demo
- , 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.