Comp 1807 Week6

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 35

COMP 1807

Agile Development with SCRUM


We e k 6 – S p r i n t i n g
Matt Prichard
This week
The Sprint planning and Sprint Backlog

• Potentially releasable product increment

• The Scrum task board

Artefacts and rituals

• Measuring Sprint progress

• Burndown and Burnup Charts

• Daily Scrum and Impediments


Sprint Planning Meeting
Right at the start of each new Sprint
• Plan is created by the entire Scrum team – Dev Team, PO, Scrum
Master
• Product owner should come prepared to talk about 2 sprints
worth of work

Time-boxed - 8 hours for 1 month Sprint


• Proportionately less for shorter Sprints (2 hours for every week
of sprint)

Meeting split in two parts (each half of overall


duration)
Sprint Planning part1 – what will be done ?
Input to this meeting:
1. Review of Potentially Shippable Product Increment
2. Up to Date Product Backlog, users stories should be
ordered and estimated with acceptance criteria created
and a clear definition of Done.
3. If known (if this is not 1st Sprint), past performance of
Development team – Velocity - (e.g. how much work can
they usually achieve in a Sprint)
4. Projected capacity/performance during the sprint.
Sprint Planning part 2 – what will be done cont…

 Product Owner presents the Ordered Product Backlog Items


 Entire Scrum team collaborates to understand each Product
backlog item before it’s included in the Sprint
 Development team agrees the users stories that can be
delivered from the Sprint
 Number of Product Backlog items/user stories selected is
up to the Development team and based on the user stories
estimation and discussions

Entire Scrum Team then crafts the Sprint Goal


Potentially Shippable Product
Increment
The purpose of each Sprint is to deliver an
increment of potentially releasable
functionality that adhere to the Scrum
Team’s current definition of “Done”.
Each is additive to all prior Increments
• Integrated and thoroughly tested
• Ensuring that all increments work together

This means that Each Sprint must include:


• Integration of any changes or new functionality with
previous increments
• Refactoring of the design of previous increments as
necessary
• Regression testing of previous increments
Each increment from a Sprint is useable
So the Product Owner may choose to release it
Thus each increment is called “potentially shippable”
Sprint Goal
Sprint Goal
 Short statement/objective set for the Sprint. What is
wanted and how it will be measured.
 Must be realistic and SMART (Specific, measurable,
achievable, relevant, timely)
 Provides guidance to the Dev team and facilitates
prioritisation
 Which stories should be worked on in the next cycle.
 The selected Product Backlog items for the Sprint should
deliver at least one coherent function which can be the
Sprint Goal
Examples of Sprint Goals
• In this Sprint, we will allow users to create a profile, log in to the site,
retrieve a forgotten password and manage their profile.
• In this Sprint, we will implement basic shopping cart functionality
including add, remove and updated features

First define the goal.


Then explore which epics have to contribute to it
Break out small detailed stories from the epics.
Order the new ready stories based on their contribution to the
goal.
Sprint Planning - How will the work get done?

Having set the Sprint goal and chosen the Product Backlog
items for the Sprint the Dev Team decides how it will build
this functionality into a “Done” product Increment during the
Sprint.

1. Decide how to achieve the Sprint Goal


2. Clarify requirements further and negotiate trade-offs
• Product Backlog items/user stories are further broken down to
a more granular level – so called task level
• Tasks are the smallest unit used in scrum to track work.
Each user story will have multiple associated
tasks
Created by function such as design, code, test,
document, or UX
Tasks are then estimated in man hours
Each task shouldn’t take more than a day to be
completed
Scrum Board

A Scrum board is a visual display that tracks projects in either a


physical or virtual format. The board is divided into vertical
categories showing the progress of a time-based project called
a sprint.
Sprint Backlog
Output of Sprint Planning:
The set of Product Backlog items selected to be done in the
Sprint with their associated tasks
Created and owned by the Dev team – only they can change
it
Kept up to date every day
• Initial tasks are identified by the team during the Sprint planning
• Team will discover additional tasks needed to meet the Sprint Goal
during the Sprint execution
• Modified throughout the Sprint, as new information is available and
as tasks are moved from to Do to Done.
• As work is completed, the estimated remaining work is updated
The Sprint
The sprint
A time-boxed event with a goal to produce a “Done”, working,
useable, and potentially releasable product increment at the end
of it.
• Has a definition of what is to be built, a flexible plan that will
guide building it, consists the work and the resultant product.
• 2-4 weeks per Sprint
• Best to have consistent duration throughout life cycle of the
project
The sprint
Each Sprint consist of the
following:
• Sprint Planning
• Daily Scrum Meetings
• The Velocity/Burndown Chart
• The Development Work
• Product Backlog Refinement
• The Sprint Review
Monitoring Progress
• Total work remaining in the Sprint

Backlog can be summed at any time in the Sprint


• Development team tracks progress

(work remaining) at least for every Daily Scrum Meeting


• To assess likelihood of achieving Sprint Goal
• In order to manage its progress
• Sprint Burndown/burnup are
charts representing progress of
work during the Sprint.
Burndown or Burnup charts
• Both charts represent the same information, work remaining or work
completed should be measured every day and presented at the Daily
Scrum Meeting.
• Your coursework requires burndown charts.
Burndown charts
Example burndown chart
10 day Sprint and user stories worth of 55 points to be completed in the
Sprint.
Burndown chart: calculate the user stories completed every day – (user
stories which have moved from the “to do” to the “Done” column of my
Scrum board). The user story points remaining by the end of the day are
indicated in the chart.
• If a story is not completed = 0
• By the end of this Sprint only 45 user

story points were completed.


• 10 left and they will have to be moved
Excel version on Moodle
Daily Scrum
Daily Scrum Meeting
A meeting to synchronise the team and plan for the next
24 hours
• 15 minute time box, same time and place, every day of the
Sprint
Development team
• Assesses progress toward Sprint Goal
• Update burndown/burnup charts and make decisions
• Update Sprint Backlog (e.g. more post-it notes, add more tasks)
• Review Impediments
Benefits of Daily Scrum
• Eliminate other meetings
• Identify and remove Impediments
• Promote quick decision making - Improve communications and
knowledge
• Foster sense of team commitment
Daily Scrum in Practice
Scrum Master ensures that Daily Scrum happens
• Development team is responsible for doing it

Only Development team should participate


• Product Owner may observe
• Scrum Master may or may not participate, but they facilitate

Three questions:
1. What has been accomplished since last meeting?
2. What will be accomplished today and before next meeting?
3. What obstacles/impediments are in the way?
Complex issues taken off-line
Tips for dealing with impediments
• Make the Impediments visible – use special colour post it notes
for them
• Search for impediments. Look out for impediment words, (“still
waiting”, “not available”, “hopefully”, “wish”, “guess”,
“expected”, “ I thought”, “try”)
• Limit the number of impediments. Select 3 biggest ones and
put a big read dot on each of them. It will help the team focus.
• If the team cannot resolve them then it is the Scrum Master’s
role to find a way to resolve them.
Wrap Up
• Sprint includes Sprint planning, development work, product
backlog refinement, Daily scrum, review and retrospective
meeting
• Using the Kanban board to make work visible – To do, Doing,
Done
• Monitoring progress throughout the sprint by measuring how
many user story points have been completed
• Visually representing this information daily in burndown/burnup
charts
• Daily Scrum Meeting – 3 questions asked to every development
team member
?

You might also like