17spm_L14
Scrum
SPM 2017 © Ron Poet Lecture 14 1
Introduction
Scrum
� Scrum is a framework for management of iterative and incremental
product development.
o It can be used for non-software products.
� It was invented in Japan in 1986 for development of commercial
products that gave increased speed and flexibility.
SPM 2017 © Ron Poet Lecture 14 2
products that gave increased speed and flexibility.
o A scrum is used to restart a game of Rugby after a minor
infringement.
� It was applied to software projects in the early 90s.
� It is a framework for managing complex projects.
o The details can use other approaches such as XP.
Scrum Theory
� Experiential learning theory (Learn by doing).
� Knowledge and understanding come from:
o Planning something.
o Doing it.
o Reviewing how it went.o Reviewing how it went.
o Adapting the process to be used in the next iteration.
� Transparency
o The process used is visible to everyone.
� Inspection
o Frequently check how the work is going.
� Adaptation
o Change the process if improvements can be made.
3SPM 2017 © Ron Poet Lecture 14
The Scrum Team
� Product Owner: responsible for the business value of the product
(customer). Selects what gets done and when
� Scrum Master: ensures the team is motivated and productive.
Removes obstacles. Ensures proper processes are followed.
� Team:
SPM 2017 © Ron Poet Lecture 14 4
� Team:
o Between 3 and 9 people including product owner and scrum
master.
o Developers and Testers.
o User Experience analyst.
o Customer / User.
The Scrum Master
� Not a team leader! The team is self-organising!
� Works with the Product Owner
o Helps them define the product backlog (stories)
o Translates the product owners language into words the team will o
understand.
� Works with the team members
o Facilitates the events.
o Coaching and teaching.
o Removing impediments.
� Works with the rest of the organisation.
o Liase with other scrum masters.
5SPM 2017 © Ron Poet Lecture 14
Sprints (Iterations)
� From a forward’s point of view, a game of rugby consists of a series of
sprints between scrums.
� Between 1 and 4 weeks, typically 2 weeks.
� They are timeboxed (must end on time).
SPM 2017 © Ron Poet Lecture 14 6
� The goals, sprint backlog and team are fixed.
� If a story can’t be finished, it is put back in the product backlog.
� If problems come to light during a sprint, the team will try and fix
them in the sprint.
� Problems that can’t be fixed in the sprint generate stories to be added
to the product backlog.
� An entire sprint can be dedicated just to fixing problems.
Sprints (2)
� Risk managements
o Inspection of the product and process happens at the end of each
sprint.
o The maximum amount of work that could be wasted is one sprint’s
worth.worth.
o This reduces the risk that the project goes down a dead end for a
long time.
� Sprints can be cancelled by the product owner before the end of the
timebox.
o New information from the sprint shows it is not worth continuing.
7SPM 2017 © Ron Poet Lecture 14
Scrum Events
� Sprint (iteration) Planning at the start:
o The team and Product Owner agree on what to do in the sprint.
o The meeting is timeboxed for 4 hours (for a 2 week sprint).
o The stories to be included are chosen.
8
o
o The product owner then leaves and the work is divided up.
� Daily Scrum: Team stand up meeting at the start of each day.
o Timeboxed at 15 minutes. Only the team members speak.
o What did you do yesterday
o What will you do today.
o Are there any impediments standing in your way. The scrum
master will try and remove them.
8SPM 2017 © Ron Poet Lecture 14
Scrum Events (2)
� Sprint Review: at end of the sprint.
o Timeboxed to 2 hours (for 2 week sprint)
o Product owner identifies what has been done.
o Team discuss what went well, what not so well.o
o Team demonstrate the work they have done.
o Product owner discusses the remaining product backlog and likely
completion date.
o Discussion on what to do for the next sprint.
9SPM 2017 © Ron Poet Lecture 14
Scrum Events (3)
� Sprint Retrospective: Look for possible improvements.
�Timeboxed to 1.5 hours ( for 2 week sprint)
�How the sprint went: people, relationships, processes and tools.
�What went well.
�Develop a plan to implement improvements.
10SPM 2017 © Ron Poet Lecture 14
Iteration Length and Velocity
� Iterations are all the same length, to establish a rhythm.
� Typical iteration lengths are between 1 and 4 weeks.
� The iteration velocity will then be the expected number of story points
(ideal days) that can be completed in each iteration.
11
o An initial estimate of the velocity must be made for the first
iteration, but it can be modified for later ones in light of
experience.
� The estimated project length in iterations will then be the total number
of story points on all the user stories divided by the velocity.
o The velocity is the same for all iterations.
SPM 2017 © Ron Poet Lecture 14 11
Planning an Iteration
� An iteration will consist of a small number of stories.
� The team discuss the stories in priority order.
o The customer must be there to answer questions.
� Each story is split into individual tasks.
12
o This is where detailed design happens.
� The developers pick the tasks that they want to work on.
� They estimate the time needed for all their tasks.
o Usually in ideal hours.
� They make sure they are not overcommitted.
SPM 2017 © Ron Poet Lecture 14 12
Monitoring Velocity
� It is useful to measure predicted and actual effort expended on each
story and the iteration as a whole each time an iteration is completed.
o Actual velocity is calculated by only measuring completed stories.
o Don’t create an incentive to have many nearly finished stories at
the end of an iteration.
13
the end of an iteration.
� Each story will have two numbers, predicted and actual effort.
� Only use the predicted effort to calculate actual velocity.
o Encourage accurate predictions.
o Don’t reward taking too long.
SPM 2017 © Ron Poet Lecture 14 13
Story Points Completed Graph
� This is similar to the value added graphs in other methodologies.
� The x-axis measures the iterations.
� The y-axis measures story points completed, with two sets of points:
predicted and actual.
14
� Additional stories and story points can be added during the project.
� The actual points and number of iterations for the predicted and actual
graphs can be different.
� New stories don’t appear on this graph, so …
SPM 2017 © Ron Poet Lecture 14 14
Iteration Burndown Chart
� This is similar to the story points completed graph but …
� It measures the work still to be done rather than the work already done.
� Both predicted and actual graphs start with the initial estimate of total
story points.
15
� This value is adjusted at the end of each iteration by:
o Subtracting the story points completed.
o Adding points for new stories creating.
o Adjusting for changed estimates of existing stories that have not
started.
� The graphs can go up at the end of an iteration if a lot more work is
discovered while working on it.
SPM 2017 © Ron Poet Lecture 14 15
Planning Releases
� Not every iteration results in a new release.
� We might fix the release date in advance.
o This will give us a limit on the number of story points that can be
achieved.
16
o We can then decide what goes into a release, based on this
constraint.
� We might want a given functionality for the release.
o Decide which user stories are needed to achieve this functionality.
o Add up the story points and decide how many iterations are
needed.
SPM 2017 © Ron Poet Lecture 14 16
The Release Plan
� Each release will consist of a number of iterations.
� Each iteration will be a pile of story cards.
� Decide which pile a story card goes into depending on priority.
� Make sure each iteration is roughly the same length.
17SPM 2017 © Ron Poet Lecture 14 17
Story Priorities
� Thinking about releases will encourage the customer to decide on the
priorities for each user story.
o Must have …
� The priority will often depend on the cost.
18
o Expensive stories that provide little additional functionality will
have a lower priority.
� There are 2 approaches to risky stories.
o Do easy stories first and learn. Risky stories then become easier.
o Do the risky bits first if the story is essential.
SPM 2017 © Ron Poet Lecture 14 18
The Lives of Stories
� Stories are discovered in the initial requirements gathering stage and added to
the product backlog.
� They are given a priority.
o High priority items are refined in more details, perhaps turning into
several stories.several stories.
o Low priority items remain at a lower level of detail (epics).
� They are ready to be added to a sprint backlog when:
o Any prerequisites have been completed.
o They have a reliable estimate of effort required.
� Estimates can be updated and items re-sequenced as the product is developed.
� They are finished when they are ready to be used by the product owner.
o Thoroughly tested.
19SPM 2017 © Ron Poet Lecture 14
Scrum Artefacts
� Product Backlog: Prioritised list of stories.
o Rough estimates of business value, priority (by the product owner).
o And effort involved, story points (by the team).
� Sprint Backlog: Stories for this sprint.
SPM 2017 © Ron Poet Lecture 14 20
o Stories broken down into tasks.
o Each task between 4 and 16 ideal hours work.
o Tasks chosen by team members.
� Burn Down Charts: work remaining on the current sprint, current
release and the overall project.
o Sprint chart updated daily.
� Hit rate: how much of each sprint was completed.
Scrum Meetings
� The sprint planning meeting lasts half a day day.
o The product owner describes the highest priority items and defines
a goal for this sprint.
o The developers select the items they think they can complete
during the sprint.
21
during the sprint.
� The sprint review meeting is at the end of the sprint. No more than 2
hours are allowed for preparation and powerpoint is banned!
� Daily short scrum meetings: what did you do yesterday, what will you
do today, are there any obstacles?
SPM 2017 © Ron Poet Lecture 14 21
Signs of Problems
� A frequent need to revise estimates could mean that the stories are too
small.
� Difficulties planning iterations because of dependencies between
stories.
o Try splitting bigger stories differently.
22
o Try splitting bigger stories differently.
� Gold plating by developers – adding features that were not planned.
o Avoid making things more complicated than needed.
� Run out of space on the cards could mean too much time spent writing
about a story.
o Could also be caused by thinking too far ahead.
SPM 2017 © Ron Poet Lecture 14 22
Signs (2)
� Don’t keep splitting stories to make each iteration have just the right
number of story points.
o Estimates of effort are not that precise.
� The customer has trouble prioritising.
23
o The stories are probably too big.
� The customer won’t write and prioritise stories.
o Usually a symptom of a blame-based organisation.
o Find ways for customers and users to express an opinion without
the customer taking responsibility if it goes wrong.
SPM 2017 © Ron Poet Lecture 14 23