Agile Scrum Training

(1)

Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

AGILE SCRUM WORKSHOP

Tài liệu được biên soạn bởi Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

Author : Nguyễn Thành Châu E-‐mail: [email protected] Cell phone: (+084)918226449

(2)

Introductions and Expectations

Participant introductions v  Name

v  Position and background

v  How long experience with Agile-Scrum development?

v  What do you want to get out of this course (expectation)?

(3)

Who Am I ?

q  20+ years of working experience in IT industry

q  Conducted 50+ training courses related to Agile-Scrum, PM, BA, CMMI, ITIL, ISO 20k, ISO 27k.

q  Consulted 20+ organization related to QMS, ISMS, ITSM q  Professional Scrum Master

q  ISMS Lead Auditor q  ITIL Expert

(4)

Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của

Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT 4

Logistics

EMERGENCY

(5)

Rules of Engagement

v  Participate.

v  One person speaks at any given time.

v  Keep discussions and questions to the point.

v  Turn on your cell phones and other communication devices to Silence mode.

v  Be prompt returning from breaks. v  ……

(6)

AGENDA

v  Traditional Software

Development

v  Agile Introduction

v  Agile Scrum Introduction v  Scrum Roles v  Scrum Artifacts v  Scrum Meeting v  Agile Estimation v  Agile Requirement v  Testing in agile

v  Agile - Lean development v  KanBan

v  Scaling and Distributed Scrum v  Extreme Programming

(7)

Schedule

Day 1 :

v Traditional Software Development v Agile Introduction

v Agile Scrum Introduction v Scrum Roles

Day 2 :

v Scrum Artifacts v Scrum Meetings v Agile Estimation

(8)

Schedule

Day 3 :

v  Agile Requirement v  Testing in agile

v  Agile - Lean development

Day 4 :

v  Agile - Lean development v  KanBan

v  Scaling and Distributed Scrum v  Extreme Programming

(9)

S

c

h

e

dule

Day 5 :

v  Agile For Manager v  Workshop summary v  Mockup exam

(10)

(11)

Software

Engineering

“ The application of a systematic, disciplined,

quantifiable approach to development,

operation and maintenance of software: that

is, the application of engineering to software.”

(12)

Exercise 1: Explain waterfall model

Traditional model:

v  List all of phases of Waterfall model. Each phase will be written in a sticker.

v  List all of roles of Waterfall model. Each role will be written in a sticker. v  List all of the tasks of Waterfall model. Each task will be written in a

sticker.

v  List all of problems, issues, or weaknesses of Waterfall model. Each problem, issue, or weakness will be written in a sticker.

(13)

The

T

raditional

Development

v Analysis

v Design

v Coding

v Testing

(14)

(15)

The

T

raditional

Development

-

Assumptions

Traditional model is a good fit when:

v  Customer knows all requirements upfront v  Requirements are stable

v  Technology is well known and mature v  The problem has been solved before v  Everything goes as per plan

(16)

What

are

the

trusts

?

v  The client doesn’t know what they want

v  The client thinks they know what they want but are wrong v  We don’t understand what the client wants

v  We think we understand but we are wrong v  We don’t know how to do it

v  We thought we knew how but we were wrong v  Changes to external factors alter the objectives

v  The client has learned along the way that they now want something different

(17)

Weakness

of

traditional

software

development

method

v  All good ideas should come in the beginning, a good idea at the release stage is a threat

v  Emphasis on writing things down – leads to lack of clarity in thought and understanding

v  Last minute correction not possible

(18)

The Traditional Process

Analysis

Design

Coding

Tes0ng

Time

(The cost of change increases)

Do we have ½

ﬁnal product yet?

(19)

Legacy

of

waterfall

Model

v  Ask Customers what they want §  When they really don’t know

v  Reward them for thinking everything upfront §  And manage that as ‘scope’

v  Penalize them for adding things later §  Do strict ‘scope’ control

(20)

Features

of

traditional

software

v  Biggest cost of Predictive Development is over

production of features v  Must be designed, built

and maintained

v  Don’t get used, provide no value Always Used 7% Frequently _Used 13% Some0mes Used 16% Rarely Used 19% Never Used 45%

(21)

(22)

Video

demo

2 0 Oracle Agile P

L

M C

u

stomer

(23)

What

is

Agile

Software

Developmen

t

?

In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized:

v  close collaboration between the programmer team and business experts;

v  face-to-face communication (as more efficient than written documentation);

v  frequent delivery of new deployable business value; v  tight, self-organizing teams;

(24)

Agile

Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.

(25)

Principles

behind

the

Agile

Manifesto

1

•  Our highest priority is to satisfy the customer

through early and continuous delivery of valuable so_ware

2

•  Welcome changing requirements, even late in

development. Agile processes leading the change for the customer’s compeccve advantage.

3

•  Deliver working software frequently, from a

couple of weeks to a couple of months, with a preference to the shorter cmescale.

(26)

Principles

behind

the

Agile

Manifesto

4

•  Business people and developers must work

together daily throughout the project.

5

•  Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.

6

•  The most eﬀicient and effective method of

conveying information to and within a

(27)

Principles

behind

the

Agile

Manifesto

7

•  Working so_ware is the primary measure of

progress.

8

•  Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indeﬁnitely.

9

•  Concnuous ahencon to technical excellence and

(28)

Principles

behind

the

Agile

Manifesto

10 •  Simplicity the art of maximizing the amount

of work not done is essencal.

11 •  The best architectures, requirements, and

designs emerge from self-‐organizing teams.

12 •  At regular intervals, the team reflects on

how to become more effective, then tunes

and adjusts its behavior accordingly.

(29)

Agile

Process

A N A L Y S I S

D E S I G N

C O D I N G

T E S T I N G

The best way to manage

‘scope’ is to write less

code!

• Develop 20% of features

that deliver 80% values

• Develop and deploy

highest priority ﬁrst

• Stop when you run out of

0me or money

20% done 100% usable

(30)

Waterfall Model vs. Agile

Process

Time

Analysis

Design

Coding

Tes0ng

Time

Analysis

Design

Coding

Tes0ng

(31)

Some

advantages

of

the

Agile

approach

v  The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project.

v  The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.

v  If time to market for a specific application is a concern, Agile can more quickly produce a basic version of working software.

v  Development is often more user-focused, likely a result of more and frequent direction from the customer

(32)

Some

disadvantages

of

the

Agile

approach

v  The very high degree of customer involvement may present

problems for some customers who simply may not have the time or interest for this type of participation.

v  Agile works best when members of the development team are completely dedicated to the project.

v  Time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the Time-boxed. Additional sprints may be needed, adding to the project cost.

(33)

Some

disadvantages

of

the

Agile

approach

The iterative may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project.

(34)

Exercise 2: Drawing a picture

Draw a picture based on Waterfall model – 20 minutes

v  Customer looks at a picture carefully.

v  Customer explains the picture to the team.

v  The team listen requirement from customer and take a note. v  The team draw a picture.

Draw a picture based on Agile – 20 minutes

v  Customer looks at a picture carefully.

v  Customer joins with the team to draw the picture.

v  Every 5 minutes, customer can look at the original picture and come back with the team.

(35)

(36)

(37)

(38)

Agile

Methods

v  Scrum

v  Extreme Programming

v  Adaptive Software Development (ASD)

v  Dynamic System Development Method (DSDM) v  Feature Driven Development (FDD)

v  Lean Software Development v  Lean/Kanban

(39)

Video

demo

1 .

F

ive

L

evels of Agile Pla

nn

i

n

g

2. Agile

vs

Tra

dition

a

l

Syst

em

D

ev

elopme

n

t

(40)

(41)

SCRUM

(42)

Video

demo

(43)

History

of

Scrum

v  1995

§  Analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes

§  Design of a new method: Scrum by Jeff Sutherland and Ken Schwaber

§  Enhancement of Scrum by Mike Beedle and combination of Scrum with extreme programming

v  1996

§  Introduction to Scrum at the OOPSLA conference v  2001

§  Publication of the Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

(44)

What

is

Scrum

used

for?

v  US FDA-approved software for X-Rays, MRIs v  High availability systems (99.9999% uptime) v  Enterprise workflow systems

v  Financial payment applications v  Large database applications v  Embedded systems

v  ISO 9001 organizations

v  CMMi Level 5 organizations

(45)

(46)

(47)

(48)

What

is

Scrum?

“

S

cr

um

i

s a

fra

m

ew

o

r

k

fo

r d

evelo

p

i

ng

co

mp

le

x

product

and systems.

It is grounded in empirical process and control theory.

Scrum employs an iterative and incremental approach to

optimize predictability and control risk.”

(49)

A

Management

Framework

v  Scrum is a management framework for incremental product

development using one or more cross-functional, self- organizing teams of about seven people each.

v  It provides a structure of roles, meetings, rules, and artifacts. v  Teams are responsible for creating and adapting their processes

within this framework.

v  Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long.

v  Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration

(50)

Scrum

Framework

v  Scrum is designed to add energy, focus, clarity, and transparency to project planning and implementation. It will:

§  Increase speed of development

§  Align individual and corporate objectives §  Create a culture driven by performance §  Support shareholder value creation

§  Achieve stable and consistent communication of performance at all levels

(51)

Scrum

Has

Three

Legs

Transparency

Inspeccon

Adaptacon

We all know what

Is going on _{Check
your
work} as you do it.

OK to change tacccal direccon

(52)

Scrum

V

alues

v  Commitment Scrum asks you to commit to a goal and then

provides you with the authority to meet those commitments.

v  Focus It insist that you focus all your efforts on the work

you’re committed to and ignore anything else.

v  Openness Openness is prompted by the fact everything about a

scrum project is visible to everyone.

v  Respect Scrum tenets acknowledge that the diversity of team

members’ background and experience adds value to your project.

v  Courage Finally, Scrum asks you to have courage to commit ,

(53)

(54)

Product

Owner

NO CHANGE in Duracon or Goal

SPRINT

•  Product Owner decides what should be produced so as to achieve success

•  Gets inputs from end users, team managers, stakeholders, execucves, industry experts etc

•  Produces the product backlog which contains the features of the product to be produced in order of priority

(55)

Product

Backlog

•  The Product Backlog is the single master list of features,

funcconality etc… prioriczed based on business value and risk

•  The Product Backlog is constantly being revised by the Product Owner, to maximize the business success of the team’s eﬀorts

(56)

Scrum

T

eam

•  Ideally consists of 7+/-‐ 2 people

•  The team has to be cross funcconal – containing members from the diﬀerent verccals required for developing the product

• The team is self organizing and self managing – makes a commitment and manages its responsibilices

(57)

Sprint

• Sprint is referred to the ﬁxed period of cme the team commits to work in course of developing the product

• The length of the sprint is decided by the Team and the Product Owner

• Working at a sustainable pace is important to avoid burn out

(58)

Sprint Planning Meeting

•  Before each Sprint, the team selects what it will commit to deliver by the end of the Sprint.

•  The team creates a task-‐level plan for how they will deliver.

•  The team works together to create an inical assignment of tasks, and compares total

escmated task hours with total escmated

available hours, to make sure the commitment is reasonable.

• Everyone on the team takes part, regardless of experience-‐level

(59)

Sprint

Backlog

•  The Sprint Backlog lists all the tasks, and the hours remaining for each.

• The Task Board shows where tasks are in progress.

•  The Sprint Backlog is updated every day by

(60)

The

“no

change”

of

Sprint

• During the Sprint, what the team

commihed to deliver does not change, and the end-‐date of the Sprint does not change.

• This enables team to make and keep commitments, it gives the team focus

and stability during the Sprint, and it

trains Product Owner to clearly think

through what is on the Product Backlog.

• If something major comes up,

Product Owner can direct the team to terminate the Sprint prematurely, and start a new one

(61)

The

“no

change”

of

Sprint (con

t

inue)

NO CHANGE in Duracon or Goal • In return for not making changes

during the Sprint, Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint.

• Product Owner can add, remove,

reorder, or change items. They can also ask the team to re-‐implement work that’s already been completed.

(62)

Daily

Standup

Meeting

Each day, the team has a short meecng to update each other on progress and surface blocks. They stand up, to keep it fast.

• To keep the meecng to 15 minutes, everyone reports just 3 things: done since yesterday, done by tomorrow, and blocks.

• Scrum Master notes blocks, and a_erwards helps resolve them.

• Others can ahend the meecng if the team invites them, but they do not speak. This meecng is not for monitoring team

(63)

Burnt-down

Chart

Each day, the team updates simple charts that make visible how they are progressing towards their goal for the Sprint.

• The Sprint Backlog lists all the tasks, and the hours remaining for each. The Burn-‐down Chart graphs the total hours le_ for all tasks. The Task Board shows where tasks are in progress.

• These charts enable the team to successfully self-‐manage and deliver what they commihed to by the end of the Sprint

(64)

Scrum

Master

The ScrumMaster is a new role. It can be played by an exiscng person (such as a

former Project Manager or team-‐member). • The ScrumMaster serves the team

(helping them remove any and all

impediments that surface), protects the team (from any outside disrupcon or interference), and teaches and guides the team’s use of Scrum.

• Without a ScrumMaster, the team has a high risk of failure.

(65)

Finished

W

ork

The aim for the team is to complete 100% of what they commihed to, ideally an increment of Potencally

Shippable Product at the end of each Sprint.

• For so_ware, this means funcconality that has been designed, fully implemented, and fully tested, with no major defects.

• Few teams can do product Potencally Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.

(66)

Sprint

Review

Meeting

At the end of the Sprint, the Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced.

• The Product Owner gathers feedback from everyone on ways to improve what’s been built.

(67)

Sprint

Retrospective

The Team, Product Owner, and Scrum Master meet at the end of each Sprint to review their way of working, and look for ways to improve their eﬀeccveness.

• This is the mechanism for concnuous improvement, and also

where criccal problems are idencﬁed and addressed, or surfaced to management for assistance

(68)

Components

of

Scrum

Scrum Ceremonies (Events) Scrum Roles

Scrum

Ar0facts

(69)

Benefits

of

Scrum

v  Improvement Statistics: §  Productivity Improvement – 68% §  Team Morale – 52% §  Adaptability – 63% §  Accountability – 62%

(70)

Challenges

of

Scrum

v  Inability to get everyone involved with planning

v  Failure to have dedicated roles –Scrum Master, Product Owner and Team v  Product Owner that isn’t ready for the team

v  Teams lacking authority and decision-making ability v  Ineffective use of the retrospection

v  Obtaining only “checkbook commitments” from executive management v  Failure to pay attention to infrastructure required

(71)

Summary

v  It is an iterative, incremental framework

v  Sprints – cycles of work developed, duration 2 – 4 weeks; occur one after another without pause

v  Time-boxed – they end whether or not the work ends

v  At the beginning, cross-functional team forms the priority list based on customer requirements

v  During the sprint the chosen items do not change v  Everyday inspection and adjustment

v  End of the sprint, review with stakeholders

v  Feedbacks are taken and incorporated into the sprint

(72)

Video

demo

(73)

Exercise 3: SCRUM Roles

SCRUM:

v  List all of roles of SCRUM. Each role will be written in a sticker. v  Put all of the tasks of Waterfall model match to SCRUM roles.

(74)

(75)

Scrum Roles

(76)

(77)

Roles

-

Chickens

v  “Chicken” roles

Chicken roles are not part of the actual Scrum process, but must be built.

v  Stakeholders (customers, vendors)

These are the people who enable the project and for whom the project They are only directly involved in the process during the sprint reviews.

v  Managers

People who will set up the environment for the product development organizations.

(78)

Roles

-

Pigs

The Pigs are the ones committed to the project and performing the

actual work of the project.

Scrum

Team

Product

Owner

Scrum

Master

(79)

Product

Owner

Role

v  Single person responsible for maximizing the return on investment (ROI) of the development effort

v  Responsible for product vision

v  Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans

v  Finalize the answer for requirements questions v  Accepts or rejects each product increment

v  Decides whether to ship

v  Decides whether to continue development v  Considers stakeholder interests

v  May contribute as a team member v  Has a leadership role

(80)

Product

Owner

Role

The Product Owner is responsible for maximizing the value of the product

and the work of the Development Team.

The Product Owner is the sole person responsible for managing the Product

Backlog, includes:

v  Clearly expressing Product Backlog items;

v  Ordering the items in the Product Backlog to best achieve goals and missions;

v  Optimizing the value of the work the Development Team performs;

v  Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

v  Ensuring the Development Team understands items in the Product Backlog to the level needed.

(81)

As

a

Scrum

Product

Owner

Y

ou…

v  Hold the vision for the product on behalf of the business, the customer, and the user.

v  Represent the interests of the business to the team. v  Represent the product and the team to the business. v  Communicate with stakeholders regularly.

v  Write user stories.

v  Help others write user stories.

v  Understand the business value of each user story. v  Assign numeric business value to each user story.

(82)

As

a

Scrum

Product

Owner

Y

ou…(continue)

v  Identify acceptance criteria for each story.

v  Collaborate with the rest of the team to create the team’s definition of done. v  Accept or reject completed work, determining whether it has met the

acceptance criteria.

v  Resolve conflicting requirements from stakeholders.

v  Provide the information that the team needs to estimate each story. v  Make yourself available to answer the team’s questions about

requirements and business value.

v  Make the call in the rare instances when a sprint needs to be terminated early.

(83)

As

a

Scrum

Product

Owner

Y

ou…(Continue)

v  Clarify requirements for the team.

v  Lead the first part of the sprint planning meeting. v  Lead the story time meetings.

v  Gather feedback from stakeholders at the sprint review. v  Do not hold the role of scrum master.

v  Do not do implementation work.

v  Do not tell the team how to do the work. v  Do not estimate stories

(84)

Video

demo

(85)

Exercise 4: Product Owner Role

SCRUM:

v  List all of the tasks of a product owner and put the tasks under Product Owner role on the board.

(86)

Scrum

T

eam

(87)

The

Development

T

eam

role

The Development Team consists of professionals who do the work of

delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

Only members of the Development Team create the Increment. v  They are “self-organizing”

v  They are “cross-functional”

v  They decides “what to commit to”

v  Scrum recognizes no titles for Development Team members v  Scrum recognizes no sub-teams in the Development Team,

v  Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

(88)

The

Development

T

eam

role

(Continue)

v  One team normally does all the work - planning, analysis, programming, and testing

v  Negotiates commitments with the Product Owner, one Sprint at a time

v  Develops the product and gives ideas to the product owner v  Has autonomy regarding how to reach commitments

v  Intensely collaborative

v  Most successful when located in one team room, particularly for the first few Sprints

v  Normally contain 7+ or – 2 people

(89)

The

Development

T

eam

Responsibilities

v  The Scrum Team is responsible for the high-quality and timely delivery of sprint commitments in line with the expectations of the Product Manager and Product Owner.

v  The Scrum Team is cross-functional and multi-skilled they know their strengths and work together to support each other through challenging times.

v  The team members are not all experts in every area, however between them they have a wide range of abilities and areas of expertise.

v  The Scrum Team takes responsible for their commitments and are held singularly accountable for their actions and decisions -- they are as one.

(90)

The

Development

T

eam

Responsibilities

v  The Scrum Team demonstrate their output to the Product Manager and relevant Product Owner(s) and Stakeholders at the end of each Sprint.

v  The Scrum Team self-organize in order to deliver Sprint

commitments. they do whatever is required in order to deliver the highest quality/value output during a sprint. [PROACTIVE]

v  Question the Product Manager/Product Owner to ensure they fully understand the requirements of the Product Owner and end-user

(91)

Video

demo

(92)

Exercise 5: SCRUM Team Role

SCRUM:

v  List more the tasks of a SCRUM team and put the tasks under SCRUM TEAM role on the board.

(93)

Scrum Master

(94)

Scrum

Master

role

v  The Scrum Master is responsible for ensuring Scrum is

understood and enacted by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

v  The Scrum Master is a servant-leader for the Scrum Team. v  The Scrum Master helps those outside the Scrum Team

understand which of their interactions with the Scrum Team are helpful and which aren’t.

v  The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

(95)

Scrum

Master

role

v  Facilitates the Scrum process

v  Creates an environment conducive to team self-organization v  Captures empirical data to adjust forecasts

v  Enforces time-boxes

v  Keeps Scrum artifacts visible

v  Promotes improved engineering practices v  Has no management authority over the team v  Has a leadership role

(96)

As

A

Scrum

Master

Y

ou…

v  Serve as the keeper of the scrum process, “holding space” for the team.

v  Provide facilitation for team meetings during the sprint this can mean leading them yourself, recruiting an outside facilitator, or helping the team facilitate their own meetings.

v  Know when to step back and let the team learn through their own

experience, including mistakes.

v  Are available to the team and the product owner to answer questions and give advice.

v  Protect the team from outside distractions, serving as a buffer between the team and external stakeholders.

(97)

As

A

Scrum

Master

Y

ou…

v  Remove impediments for the team, so they can get on with the work. v  Are not the boss. Your role is defined by a unique set of

responsibilities, not by rank.

v  Act as an advocate for the team to the business. v  Coach the product owner in scrum practices.

v  Help the team master the use of scrum artifacts, like the task board, the sprint backlog, and burn charts.

(98)

As

A

Scrum

Master

Y

ou…

v  Lead the daily scrum until the team members are comfortable running it by themselves.

v  Run the second half of the story time meeting, or assist the team members in running it themselves.

v  Provide facilitation for, and participate in, the sprint retrospective. v  Are not the scrum police! You’re not there to tell the team what

they’re doing wrong.

(99)

Scrum

Master

Skills

v  Facilitating. v  Listening.

v  Working towards self-organizing the team. v  Leading by serving.

(100)

Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT 100

Video

demo

(101)

Exercise 6: SCRUM Master Role

SCRUM:

v  List all of the tasks of a SCRUM Master and put the tasks under SCRUM Master role on the board.

(102)

(103)

Product

Backlog

v  Is a high-level document for the entire project.

v  Force-ranked list of desired functionality

v  Contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value.

v  Visible to all stakeholders

v  Any stakeholder (including the Team) can add items to Product Backlog. v  Constantly re-prioritized by the Product Owner. Business value is set by

the Product Owner. Development effort is set by the Team. v  Items at top are more value than items at bottom

v  Maintained during the Backlog Refinement Meeting v  A Product Backlog is never Done.

(104)

(105)

Product

Backlog

-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐ -‐ _# -‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐ _# -‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐ -‐ _# -‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐ _# Product Backlog items (user stories, features, or bugs)

Estimate for each backlog item

Items are listed in top-down priority order

Agile Scrum Training

AGILE SCRUM WORKSHOP

Introductions and Expectations

Who Am I ?

Logistics

Rules of Engagement

AGENDA

Schedule

Schedule

S

c

h

e

dule

Software

Engineering

“ The application of a systematic, disciplined,

quantifiable approach to development,

operation and maintenance of software: that

is, the application of engineering to software.”

Exercise 1: Explain waterfall model

The

T

raditional

Development

v Analysis

v Design

v Coding

v Testing

The

T

raditional

Development

-

Assumptions

What

are

the

trusts

?

Weakness

of

traditional

software

development

method

The Traditional Process

Analysis

Design

Coding

Tes0ng

Time

Legacy

of

waterfall

Model

Features

of

traditional

software

Video

demo

2

0 Oracle Agile P

L

M C

u

stomer

What

is

Agile

Software

Developmen

t

?

Agile

Manifesto

Principles

behind

the

v Analysis

v Design

v Coding

v Testing

•  Simplicity the art of maximizing the amount

•  The best architectures, requirements, and

designs emerge from self-‐organizing teams.

•  At regular intervals, the team reflects on

• 

• 

• 