This document discusses agile development, focusing on the Scrum framework as a project management technique emphasizing user-centric design and team autonomy. It outlines key roles within Scrum, such as the Scrum Master and Product Owner, explains the structure of sprints, and highlights the importance of the product backlog and user stories. Additionally, it addresses the advantages and limitations of Scrum while providing examples of companies successfully employing this methodology.

1. +
Agile Development -
Scrum
Systems Analysis and Design
Michael Heron

2. +
Introduction
 We have already touched upon the basic principles behind
Agile Programming.
 Lightweight
 User Centric
 In this lecture we’re going to look at how it can actually be used
as a project management technique.
 There are several flavours of this, with several techniques for each.
 Most do not formally incorporate a project management role.
 It’s considered the purview of all members.

3. +
Agile - Scrum
 One flavour of agile development is known as Scrum.
 It’s a framework upon which you can build your own specialised
process.
 It is usually not proscriptive in terms of how things should be done.
 Instead, it gives a way in which things can interrelate.
 Core at the heart of Scrum is the idea that individual teams
know best about the problems they will have and the best
things to do to deal with them.
 It relies on a team of motivated and multitasking members.
 There’s no such thing as a team leader or project manager.

4. +
Scrum
 The entirety of the team decides on how projects will be
completed.
 And who is going to be responsible for completing parts of them.
 A large project may involve several largely autonomous teams
each tackling a subset of the problem.
 Teams are supported by two specific individuals.
 A Scrum Master
 The Product Owner.
 The latter is the ‘client’, who is involved in making sure the
thing developed is what is actually needed.

5. +
The Scrum Master
 The Scrum Master <fanfare> is the one responsible for making
sure the Scrum framework is being appropriately used.
 He/she is also responsible for balancing the teams between their
internal work and product owner requirements.
 The Scrum Master is responsible for facilitating the process,
allowing teams to work at their highest level of productivity.
 Removing roadblocks
 Facilitating meetings
 Managing the ‘Product Backlog’
 Organising and managing product ‘Sprints’

6. +
The Sprint
 Work in Scrum progresses through a series of ‘Sprints’
 A block of work, usually no longer than a month or so.
 Smaller projects may have smaller sprints.
 Sprints are ‘timeboxed’
 They are restricted to a specific duration. You can’t delay or
rechedule them.
 Sprints occur after a planning meeting.
 Tasks for the upcoming sprint are identified and allocated.
 At the end is a review meeting.
 Where progress is evaluated against commitments.

7. +
Velocity
 Scrum often incorporates a measure of team capacity known as
velocity.
 This is how much work a team can do in a particular period based
on how much work has been done in other periods.
 Two things are used to determine this.
 The Unit of work (days, hours, ‘story points’)
 Each user story in a backlog can be estimated in terms of this.
 The interval
 The most meaningful duration of work that can be done. Usually a
week.
 Velocity is calculated by units of work completed per interval.
 Initially unreliable, but with successive intervals becomes more
effective.

8. +
Velocity
 Within the Scrum team, each user stories gets allocated a certain
number of units of work.
 Story points are often used as an abstract scale – a fibbonaci
sequence, size of clothes, etc.
 This combined with velocity gives a reasonable idea of how much
can be done during an interval.
 Some teams may break it down further into velocity per individual.
 Tasks are allocated within the planning meeting until the planned
units of work match velocity.
 The projected velocity over a project lifetime gives a useful way of
determining what is likely to eventually be completed.

9. +
The Timebox
 In some project management systems, project slippage is
anticipated.
 Often represented as ‘slack’ or ‘float time’
 Within Scrum, phases are timeboxed.
 Each time box comes with its own deliverables, deadline (which is
immovable) and allocation of resources.
 Timeboxing helps limit feature creep and scope creep.
 You don’t really have the time to mess around with that kind of thing.
 As such, it is largely built on task prioritisation.
 MoSCoW being a common example of such a system.

10. +
The Product Backlog
 During a timeboxed sprint, the Product Backlog is adjusted.
 The Backlog is a prioritized feature list that is incrementally refined
during each Sprint.
 To begin with, a backlog consists of everything that can be thought
of regarding required features and tasks.
 This gets successively modified as the project changes, requirements
shift, and mastery over the project builds.
 Typically, the backlog consists of four things:
 Features to add
 Bugs that exist
 Technical Options
 Acquired Knowledge

11. +
The Product Backlog
 Some characterise the backlog as having DEEP qualities.
 Detailed appropriately
 Estimated
 Emergent
 Prioritized
 Detailed Appropriately – higher priority items are described in
more detail than lower priority items.
 This keeps the backlog tractable and focuses attention on the higher
priority tasks.
 Estimated – Each task contains a realistic estimation of the
time required to complete them.

12. +
The Product Backlog
 Emergent – As the understanding of a project changes, the backlog
will alter accordingly.
 New items get added, old items get shuffled around, detail is added (or
removed) as needed.
 Prioritized – The backlog is ordered with the highest priority tasks
shown first.
http://www.infoq.com/articles/pr
oduct-backlog

13. +
User Stories
 The simplest and most reliable way for teams to list features is
by user stories.
 These are simple descriptions of features as told from the
perspective of someone using it.
 There is a standard template
 As a <type of user> I want to <do something> so that <some
outcome>
 As a customer, I want to browse the catalog so that I can decide
what I want to buy.
 These are usually written on index cards or post-its and
arranged on walls to help facilitate the organisation of a project.

14. +
User Stories
 User stories that cover large amounts of functionality are
known as epics.
 ‘As a user, I want to manage my account so that I have control over
how the system knows me’
 Since epics are too large to be completed in a single sprint, this
gets subdivided into more manageable stories.
 Sometimes dozens or hundreds depending on how epic.
 ‘As a user, I want to change my payment details so that my
payments come from the right account’
 ‘As a power user, I want to set up email notifications for alerting
me when new things are entered into the catalogue, so I don’t
need to keep checking the site’

15. +
User Stories
 User stories become detailed enough to work with by two
mechanics.
 Splitting them up into multiple user stories.
 Adding conditions of satisfaction.
 This is a high level acceptance test that will be true after a story is
complete.
 ‘Make sure the account can be accessed on the website’
 ‘Make sure the account can be accessed via a mobile phone’
 These get specified early by the product owner for the project.
 After negotiation with the Scrum Master and scrum teams.

16. +
Writing User Stories
 User stories should ideally have the following characteristics.
 Written for specific users.
 While ‘As a User’ is appropriate for an example, it’s not detailed
enough for an actual user story.
 As a consequence of this, this aren’t written for Product Owners.
 ‘As a product owner…’
 An owner must be viewed in the context of their interaction of
the system.
 Similarly for ‘as a developer’
 Identify a value or benefit.
 They need to have the ‘because’ listed.
 Answer the questions: What if, Where, When, How.

17. +
The Structure of a Sprint
 A sprint has a certain typical structure to it.
 Planning meeting at the very start.
 Deciding on the highest priority tasks, committing to which can be
done, and then developing a Sprint Backlog accordingly.
 Daily sprint scrum meetings.
 Very short duration, usually timeboxed.
 Attended by all members, including the Scrum Master and
product owner.
 A sprint review at the very end.
 During this, the functionality developed during the sprint is
demonstrated.
 Feedback is obtained from the product owners and other
stakeholders.

18. +
Daily Scrum Meeting
 Several things get covered during the daily meeting.
 Everyone updates the team on what’s been done during the last
day.
 Everyone updates the team on what they’re planning to do today.
 Everyone reports on anything that is causing problems.
 It is the job of the Scrum Master to resolve these outside the
meeting.
 For effective time management:
 Meetings occur at the same time and place every day.
 Meetings start on time, even if people aren’t there.
 Normally only those involved in the project speak, although
everyone is welcome.

19. +
Project Burndown
 As people work on tasks within Scrum, they update the Project
Burndown chart.
 This shows the amount of work that remains in the current Sprint
and the overall project.
http://en.wikipedia.org/wiki/Fil
e:SampleBurndownChart.png

20. +
Why Use Scrum?
 There are several well documented benefits.
 Lightweight – not document free, but document light.
 Improves productivity significantly in projects where the appropriate
features are in place.
 User centric – the system involves users at all parts of the development
process.
 High visibility of progress – project burndowns and scrum meetings all
work together to create an understanding of how the project is
proceeding.
 Projects are highly adaptable – agile.
 Problems are identified early.
 Work done better meets the needs of the product owner as a result of
the backlog.
 Can deliver at any time.

21. +
Why Not Use Scrum?
 Scrum works best with experienced, motivated developers.
 While you can have a few newbies ‘normalised’ by exposure to veterans, there is
a limit to how many can be dealt with.
 Scrum works best with small, autonomous groups.
 Five to ten people are a working, realistic maximum. If you can’t subdivide a
project into teams of this size, Scrum may not be appropriate.
 Scrum works best with management and product owner buy-in.
 Some organisations are averse to these kind of techniques because they don’t
‘feel’ meaty.
 Scrum works best when projects can be effectively subdivided into sprints.
 Multi-month monolithic phases, or extremely changeable circumstances, don’t
work well.

22. +
Who Is Using Scrum?
 Lots of companies are using Scrum now.
 https://docs.google.com/spreadsheet/ccc?key=0AgfBeuoRfUzNdDlMN
G82SlhmUVRhOEk0REtrdmthNWc#gid=0
 Some examples:
 Adobe
 American Express
 The BBC (for iPlayer)
 Google
 Linkedin
 Microsoft
 They are usually not the only method used.
 But Scrum teams are embedded into many products, projects and
departments.

23. +
Conclusion
 Scrum is an agile project management technique.
 One you can profitably consider using during the module for your
assessments.
 It doesn’t do away with the need for documentation, although it
does change the emphasis.
 More emphasis is placed on meetings, scheduling and user
interaction than in other methodologies.
 Such as the waterfall model, vanilla or iterative.
 However, it is a specialised technique best used in the real
world by experienced teams.