Delivering Projects using Agile with SCRUM

* Developed and Presented by Simon Robertson, PMP, ACP, MCITP Principal Project Manager and Trainer Materials in this course are based upon The Agile Manifesto, accepted Agile and Scrum good practice reflected in the Scrum Body of Knowledge (SBOK TM Guide) 2013 Edition developed by SCRUMStudy. “SBOK” is a registered trademark of SCRUMStudy TM (a brand of VMEdu, Inc.)

Ver: 3.0 Slide 1

© 2016 Robertson Consulting Ltd

* * Not for all projects * Best for technology and platform development

* Both classic and agile can learn from each other

* Single organisation co-located team is best * Integrating Business and Project decision making is possible

* Changing requirements expected * Customer Involvement available or Product Owner appointed


* Multiple External Stakeholders

Multiple Internal Stakeholders

Single Organisation

Operational Projects

Product/Process Development Projects

Technology/ Platform Development Projects


Classic

Classic

Classic/Agile

Classic/Agile

Classic/Agile

Agile

Classic/Agile

Agile

Agile

* THE AGILE UMBRELLA

SCRUM

XP

Less Prescriptive AUP Crystal Clear


FDD

Lean

More Prescriptive DSDM

"Scrum is arguably the oldest and most widely applied agile and iterative method, with an emphasis on iterative and adaptive PM practices."

Certified ScrumMaster Trainer: Craig Larman © 2016 Robertson Consulting Ltd

* Characteristic

AGILE/SCRUM

Classic (i.e. Waterfall)

Emphasis is on

People

Processes and phases or stages

Documentation

Minimal – only if adds value or required

Comprehensive

Process Style

Empirical - Iterative

Linear or parallel

Upfront Planning

Low – just in time

High – detailed

Prioritisation of Requirements

Based on Business Value and regularly updated

Fixed in the Project Plan

Quality Assurance

Customer Centric

Process Centric

Organisation

Self-organised - flat

Managed - hierarchical

Management Style

Decentralised – collaborative

Centralised

Change

Updates to prioritised Product Backlog

Formal Change Management System

Leadership

Collaborative, Servant Leadership

Line of hierarchy, seniority

Performance Measurement

Business Value within time and cost constraints

Plan conformity – time, scope and cost

Return on Investment (ROI)

Early and throughout life of project

Generally towards end of project life

Customer Involvement

High throughout the project

Varies depending on project lifecycle Phase or Stage Slide 6


Adapted from the SCRUMstudy TM. “A Guide to the Scrum Body of Knowledge (SBOK TM Guide)”

* Cost/Budget

Scope/Functionality/Quality

Time/Schedule Customer Involvement Agreed

Quality

Agreed

Quality

Cost/Budget

Time/Schedule

Plan Driven

Scope/Functionality/Quality

Value Driven

Mirrored View

Mirrored View Customer Satisfaction

Customer Satisfaction

Slide 7 © 2016 Robertson Consulting Ltd

*

Slide 8


*

Slide 9


*

Slide 10

* * Sprint Planning * Sprint Backlog * Product created and tested * Daily Scrum * Backlog Revision * Sprint Review * Sprint Retrospective


* * Product Owner * Scrum Master * The Development Team

PRODUCT OWNER

THE DEVELOPMENT TEAM SCRUM MASTER


* Phase

Agile SCRUM Terminology

Processes

Initiate

Vision, Sprint Zero & Release Planning

1. 2. 3. 4. 5. 6. 7.

Create Project Vision Identify Scrum Master and Stakeholder(s) Form the Development Team Conduct Release Planning and Sprint Zero Develop Epic (s) Create User Stories and Acceptance Criteria Create Prioritised Product Backlog

Plan and Estimate

Sprint Zero, Sprint Planning

7. 8. 9. 10. 11.

Validate User Stories Approve, Estimate, and Commit User Stories Create Tasks Estimate Tasks Create Sprint Backlog

Implement

Sprint(s)

12. Create Deliverables 13. Conduct Daily Stand-up 14. Revise (Groom) Prioritised Product Backlog

Review and Retrospect

Scrum of Scrums Sprint Review Sprint Retrospective

15. Convene Scrum of Scrums (if required) 16. Demonstrate and Validate Sprint (Sprint Review) 17. Retrospect Sprint

Release

Product Release Project Retrospective

18. Ship Deliverables 19. Retrospect Project

© 2016 Robertson Consulting Ltd Adapted from the SCRUMstudy TM. “A Guide to the Scrum Body of Knowledge (SBOK TM Guide)”

Slide 13

* SCRUM MASTER

Customer provides Requirements

CUSTOMER

PRODUCT OWNER

Product Owner delivers Business Value through incremental product releases

Note at Programme level we may be talking about “Scrum of Scrum” teams. © 2016 Robertson Consulting Ltd

Product Owner communicates prioritised business requirements, prioritised Product Backlog and Acceptance Criteria The Development Team (Scrum Team) demonstrates the Product increment to the Product Owner during the Sprint Review

Scrum Master facilitates the Scrum processes and ensures a proper work environment for the Team

THE DEVELOPMENT TEAM Development Team create the project deliverables Slide 14

* * Responsible for : * Maximising Business Value for the project * Confirms and communicates project benefits to

PRODUCT OWNER

stakeholders

* Articulating customer requirements in the form of User Stories, Personas, and Acceptance Criteria

* Maintaining business justification for the project * Representing the voice of the customer * Captures and assesses risks for the project * Prioritises and communicates risks to stakeholders Slide 15 © 2016 Robertson Consulting Ltd

* * Typical traits held by this role’s ideal person: * Scrum Expert * Business Domain Knowledge * Excellent communication skills * Scrum processes knowledge * Ability to handle uncertainties * Negotiation skills * Approachable * Proactive * Decisive * Pragmatic * Goal-orientated



PRODUCT OWNER

Slide 16

* * Responsible for : THE DEVELOPMENT * Understanding business requirements TEAM * Estimating User Stories * Final creation of project deliverables * Ensuring project deliverables are delivered according

to agreed acceptance criteria

* Performing continuous value justification for the project

* Identifies risk and implements risk response actions required by Product Owner


* *Business Analyst *Architect or Architectural Owner THE DEVELOPMENT *User Experience Consultant (Ux) TEAM *Developer *Tester *SME – other Subject Matter Experts as required *Others?


* * Typical traits held by this role’s ideal person: * Knowledge of Scrum * Collaborative * Self-organising * Highly Motivated * Proactive * Technical Experts * Cross-functional outlook * Team Player * Independent * Responsible * Intuitive * Goal-orientated * Introspective



THE DEVELOPMENT TEAM

Slide 19

* * Responsible for : * Facilitating, guiding and teaching the Scrum

SCRUM MASTER

practices

* Providing the environment for the team to complete the development of the product successfully

* Facilitating and escalating risks identified by the team


* * Typical traits held by this role’s ideal person: * Scrum Expert * Servant Leader * Moderator * Problem Solver * Approachable * Motivator * Perceptive * Mentor * Co-ordination Skills * Introspective

SCRUM MASTER



* *Sponsor *Users/ User Groups *Project Manager *User Experience Consultant *DBA *End User Representative *Vendors/ Third Parties *Scrum Guidance Body/ Scrum Coach *PMO Slide 22 © 2016 Robertson Consulting Ltd

* SCRUM MASTER

PRODUCT OWNER

COACH

CHIEF

PRODUCT OWNER

SCRUM MASTER


KEY STAKEHOLDERS

PRODUCT OWNER

SCRUM MASTER


PRODUCT OWNER

SCRUM MASTER



* PSC

Product Owner

Project Manager

CCB

Development Team • Developer • Tester • Business Analyst • SME(s)

Scrum Master Slide 24

* * * * * * * * * * * * * * * * * *

* * Should cover the following in a short paragraph to describe the

PRODUCT OWNER

project and product:

*For: Target Customer *Why: Statement of opportunity or need *The: Name of the project or product *Is a: Product Category *That: Key Benefit or reason to use or buy *Unlike: Competition equivalent *Our Product: Statement of primary advantages Adapted from Geoffrey Moore’s Elevator Test from “Crossing the Chasm”. © 2016 Robertson Consulting Ltd

Slide 26

* PRODUCT OWNER

PRIORITISED PRODUCT BACKLOG USER STORIES - POINTS RELEASE PLAN DEFINITION OF DONE

* Owned by the Product Owner * Defined by the Product Owner * Requirements in the form of Themes/ Epics and User Stories * New requirements (User Stories) may be added * Relative Size and Complexity Story Point Estimates * Product Backlog for life! * Often needs the Development Team to assist


*

PRODUCT OWNER

Theme - Website

Story Points

Epic - Website Administration

Release

21

User Story - As an Administrator I want to manage Web content to update it (plus Acceptance Criteria)

8

1

User Story - As an Administrator I want to create new web content to provide new interest items (plus Acceptance Criteria)

8

1

User Story - As an Administrator I want to print out screen captures to assist with my management of the website (plus Acceptance Criteria)

3

2

Epic – Website Account Management

21

User Story - As an Administrator I want to manage customer accounts (plus Acceptance Criteria)

5

2

User Story - As an Administrator I want to create specific reports and statistics of customer account movement (plus Acceptance Criteria)

8

2

Epic – Customer Access

21

User Story - As a customer I wish to create a new account (plus Acceptance Criteria)

2

Epic – Customer Account Management

34

Epic – Customer Reporting

13


Note: More information and attachments are added to each User Story as more is known – including Tasks and Effort during Sprint Planning – and added to the Product Backlog.

2

Slide 28

* PRODUCT OWNER

*MoSCoW * KANO (Noriaki Kano 1985) – Products and *Must Have Customer Satisfaction – 5 types of product “Quality”: *Should have * Attractive Quality *Could have * One-dimensional Quality *Won’t have * Must-be Quality *Business Value Points * Indifferent Quality * Reverse Quality *Revenue generation *Cost Savings/ reduction *Competitive advantage * Pairwise Comparison (“Bubble comparison”) * Best way to ensure an objective view of *Others all user stories based on greatest business value © 2016 Robertson Consulting Ltd

Slide 29

* * Based on the Vision * Product Backlog created * Requires Theme and Epic decomposition * Epics need: * “T-Shirting” * Product evolution by design * Dependencies

SCRUM MASTER

PRODUCT OWNER


* Epics are time-framed – gives Road Map * Once more detail is known: * Epics become User Stories with Acceptance Criteria * User Stories “sized”– Story Points

* Roadmap becomes Release Plan © 2016 Robertson Consulting Ltd

Slide 30

* SCRUM MASTER

* For a Release Plan other Sprint Zero activities may include: * Epics decomposed to User Stories * Acceptance Criteria set * User Stories estimated * Emerging HL Design * Required Resources understood * Team roles and Agile Scrum framework/process understood * Risks understood * “Definition of Done” agreed * Governance in place

PRODUCT OWNER



*


* Theme Location

Epic

Theme Travel/ Transport

Epic

Location Choice

Epic Location Facilities

Travel to Location

Epic Transport at Location

Theme

Theme

Accommodation

Special Events

Epic

Epic

Accommodation Choice

Epic Accommodation Facilities

Special Events Day

Epic Special Events Evenings Slide 33

* Theme “Holiday Location”

Epic

Epic

“Choice of Location”

User Story “As the Client I want to choose a location that satisfies my Holiday geographical and cultural requirements”

User Story “As the Client I want to choose a location that satisfies my mix of sea, sand and sun requirements”

“Location Facilities”

User Story As the Client I want to choose a location that satisfies my sports and extra-curricular requirements”


* * Analogous Estimation – “this is like…..” * Relative size and complexity * Accounts for effort and uncertainty from experience * Not time based * Uses Fibonacci number sequence * Just-in-time planning * Helps to “get us started”

2 Smallest Slide 35 © 2016 Robertson Consulting Ltd

*

13

21

34

Small

Medium

Large

• • • •

Used for Themes and Epic level estimates Relative sizing Starts with “smallest” as a point of reference Based on Fibonacci Number Sequence


55 XX Large

Slide 36

* Milestone Date Milestone Date

Milestone Date

Theme

Epic (Feature set)

Large User Story

Large User Story

Epic (Feature set)

Large User Story

Large User Story

Large User Story

Large User Story

Release 1

Theme

Theme

Epic (Feature set)

Epic (Feature set)

Large User Story

Large User Story

Large User Story

Large User Story

Release 2 Release 3 Slide 37


*

Milestone Date Epic 34 Epic 34 Location Location Choice Facilities Large User Story

Sprint Zero

Large User Story

1

Large User Story

Large User Story

2


Epic 21 Special Events Day

Milestone Date Epic 21 Special Events Night

Epic 13 Accom Choice

Epic 13 Accom Facilities

Epic 13 Travel to Location

Milestone Date

Epic 21 Epic 13 Bookings Transp ort at Locati on

Epic Take Holiday

Large User Story

3

4

5

Weeks

6

7

8

Slide 38

* * User Roles - system access permissions * Specific User role effects on the system * Identify System Users: * Why do they use the system? * How do they use the system? * What are their priorities? * What are their characteristics?

* Typical Examples: * Default Users - read and write access only * Super Users - limited content access * Admin Users - full system Admin access Slide 39


* * Generic “Personas” based on how a typical User behaves. Covering:

* Their Profile * Goals * Likes * Dislikes * Scenario –a typical descriptive profile of this User

* Examples would be:

* Typical Customer User * Typical System Admin User * Typical Super User and so on

* Personas assist us with understanding the typical characteristics of these general product Users Slide 40


*

Slide 41

* Clive The Investment Banker Likes: History, Architecture, flora and fauna, walking, sports such as windsurfing, wave jumping, bungie jumping, motorbikes Dislikes: Club 18 Cruises, Ibiza type partying, cramped living

Profile: 30 something, no children, energetic, likes taking risks, adrenaline junkie. Scenario: I want Patsie to be happy and to enjoy celebrating our Anniversary together with some style. I need some time on my own to do crazy stuff.

Patsie “CrechesRUs” Owner Likes: History, Architecture, flora and fauna, walking, sports such as tennis, water skiing Dislikes: Club 18 Cruises, Ibiza type partying, cramped living

Profile: 30 something, no children, fairly energetic, likes sports like tennis. Scenario: I want us to have some time to make memories, as well as enjoying celebrating our Anniversary together. I know Clive needs some time on his own to do crazy stuff, but this is about us as a couple for me. Slide 42

*

User . Story

User . Story

User . Story

User . Story

*Explains what a specific User might wish to do with the product in order to achieve an outcome *Explains the functional (or non-functional) requirement from a User perspective *3 C’s: *Card – simple requirement statement from user perspective *Conversation – the story is an invitation for a conversation *Confirmation – Do we know the acceptance criteria? Slide 43


*

User . Story

User . Story

User . Story

User . Story

*User Story Meta-language: Story Title As a I want to (immediate objective)

So that (valuable gain from action)

Slide 44


* *User Stories, and related Acceptance Criteria (Product Owner) *Created during Sprint Zero and refined as needed *New User Stories may be included during “Story Times” *Based on U-INVEST model *Estimated using Relative Sizing and Complexity

User Story

User Story

User Story

User Story

.

.


.

.

Slide 45

* *U – nderstandable * I – ndependent *N – egotiable *V – aluable *E – stimable *S – imple *T - estable

User Story

User Story

User Story

User Story

.

.

.

.


* * Product Owner involves as many of the Team as possible

* Scrum Master facilitates * Objective: (using Brainstorm technique) * Identify Personas and their characteristics * Identify User Stories under identified Themes or Epics * Leave details of prioritisation and estimation to later

* Timing * Sprint Zero & Release Planning * Sprint Planning & “Story Time” Slide 47 © 2016 Robertson Consulting Ltd

* *Acceptance Criteria *Example Data – screen shot or diagram *Business Processes or Activity Diagrams *Screen Mock-ups or wireframes User Story .

Acceptance . Criteria

Business . Process Diagrams

User Story .

Acceptance . Criteria

Wireframes .


Slide 48

* Ask these questions during Story Writing:

* Split any large Stories into smaller ones? * What would the User do next? * What mistakes could the User make? * What might confuse the User? * What additional information could the User require? * What Acceptance Criteria require an additional User Story? * Covered all the User journeys for this feature/ functional set? * Do a double “backwards check” – Ask: * “If we add all the User Stories and Non-User Stories under each Epic together do I fully satisfy the functional and non-functional requirements of that Epic?”

* Missed anything? Slide 49 © 2016 Robertson Consulting Ltd

* Typical Approach Acceptance Criteria

Review ACs for current User Stories and identify Criteria which could be split into their own User Story

CRUD

Ensuring all typical functions are covered fully – changing typical management speak into BP speak! Man: Manage, Control, Setup, Maintain, Audit BP: Create, Read, Update, Delete.

Business Processes

Using Business Process diagrams or “User Journey” diagrams – identifying the steps that provides a small complete deliverable that is valuable

KANO and MoSCoW

Use KANO and MoSCoW to identify what is absolutely needed to satisfy the User needs

Minimum End-to-End (Goat Path)

Minimum set of end-to-end functionality required to get the User Story working without compromising on quality. Other features, refinements can be added later through Additional User Stories Slide 50


* *Product Owner *Every User Story *Product Owners assurance of Validation - “Done” *Validation: Are we building the right product? *Verification: Are we building the product right?


* * Meta-language “verify that…” * Covers: * How will I know when this is done? * What is my measure of satisfaction? * What is my value out from it? * How will I test it?

* Minimum specifications: * Non-functional * Design requirements * Business rules * ITIL or ISO specifications Slide 52 © 2016 Robertson Consulting Ltd

* Epic Transport at Location

USER STORY As the Client I want to have access to local transport so I can easily get around

ACCEPTANCE CRITERIA Verify that Mr and Mrs can use the transport ACCEPTANCE CRITERIA Verify that the transport can be available 247 ACCEPTANCE CRITERIA Verify that the transport safely parked when not in use ACCEPTANCE CRITERIA Verify that Driving Licenses are acceptable in location Slide 53

* *Non-functional Specifications, such as: *Performance *Usability *Scalability *Security *Infrastructure requirements, technological foundation


* *Architecture *Database *Business Process *Spike Stories *Research and analysis *Risk mitigation *Error or Defect *Maintenance/operational requirements Slide 55 © 2016 Robertson Consulting Ltd

* *Other Non User Stories *Load *Interoperability *Coexistence *BCP / DR *ITIL SLA / OLA compliance *Transition planning *Source Code Escrow


* *High Level Designs - guide and blueprint *Typical Examples include:  Business Process Models  Architectural diagrams and standards  Data Models  Interface diagrams  “Look and feel” design templates and standards *Based on complexity and size of project Slide 57 © 2016 Robertson Consulting Ltd

*

2

Small • • • • •

3

Medium

5

8

13

Large

X Large

Epic

Used for User Story level estimates Relative sizing – based on Size and Complexity Starts with “smallest” as a point of reference Based on Fibonacci Sequence Acknowledges some stories are too big and must be split


Slide 58

* *“Planning Poker©” (Mike Cohn)

SCRUM MASTER

PRODUCT OWNER THE DEVELOPMENT TEAM

* Fibonacci sequence * Involves Product Owner, Scrum Master and the Development Team * Humans estimating relative size between 1 -13

*Estimation sequence: * Identify the smallest User Story - “2” Story points * Team to individually sizes each User Story one at a time * Reveal their score * “Outlying” value estimates explain * Team reflects and re-votes. * Reveal new scores * Repeat until Agreement and Commitment © 2016 Robertson Consulting Ltd

Planning Poker © is a term registered by Mountain Goat Software (Mike Cohn)

Slide 59

* SCRUM MASTER

PRODUCT OWNER THE DEVELOPMENT TEAM

*An alternative approach – the Association or “Wall” method * User Stories distributed * Labels set up on wall - 2, 3, 5, 8, 13 etc * User Stories seen as “smallest” under “2” label * Team reviews choices and “challenges” * Challenger and challenged members explain * Team discusses “challenges”, arriving agreed result * Team size remaining User Stories * Team reviews choices and “challenges” * Challenger and challenged members explain * Team discusses “challenges”, arriving at agreed result.


Planning Poker © is a term registered by Mountain Goat Software (Mike Cohn)

* Theme “Holiday Location”

Epic

Epic

“Choice of Location”

User Story “As the Client I want to choose a location that satisfies my Holiday geographical and cultural requirements”

User Story “As the Client I want to choose a location that satisfies my mix of sea, sand and sun requirements”

“Location Facilities”

User Story As the Client I want to choose a location that satisfies my sports and extra-curricular requirements”


* * Product Owner responsibility *Typical Business Value criteria:  Revenue generation  Cost Savings  Market Opportunities  Improves Customer Satisfaction  Complies to Regulatory requirements  Improves Operational Efficiency  Mitigates Business Risk  Provides significant ROI Slide 62 © 2016 Robertson Consulting Ltd

* *Each Criterion is weighted and scaled on contribution:  Light contribution – 10 BV points  Medium contribution – 20 BV points  Large Contribution – 30 BV points  Very Large contribution – 40 BV points *Each User Story is rated for contribution *Total Contributions across all value criteria are summed *Placed in the relevant “bucket” *Prioritised by total Business Value contribution *BVPs are noted on User Stories in the Product Backlog Slide 63 © 2016 Robertson Consulting Ltd

* Revenue Generation 2x

Cost Savings 1x

Market Opportunities 2x

Improves Customer Satisfaction 1x

Complies to Regulatory Requirements 5x

Improvement to Operational Efficiency 1x

Mitigates Risks 1x

Light = 10

Light = 10

Light = 10

Light = 10

Light = 10

Light = 10

Light = 10

Medium = 20

Medium = 20

Medium = 20

Medium = 20

Medium = 20

Medium = 20

Medium = 20

Large = 30

Large = 30

Large = 30

Large = 30

Large = 30

Large = 30

Large = 30

V Large = 40

V Large = 40

V Large = 40

V Large = 40

V Large = 40

V Large = 40

V Large = 40

• How much revenue does it generate? • How quick is the ROI?

• How much cost does it save? • How quick is the ROI?

• What new Market opportunities does it provide?? • How quick is the ROI?

• How many customers requested this? • How many issues are resolved by having this?

• Is this mandatory? • When does it have to be in? • Are there legal implications or penalties?

• Do we know how much our inefficiency is costing us? • What level of improvement to efficiency with this give?

• What is the likely cost of not mitigating this risk? • When is it likely to trigger? • Are there legal implications or penalties?

Example: Enabling commercial payments via website for customers Value contributions: (2x20)+(1x10)+(2x30)+(1x30)+(5x0)+( 1x0)+(1x30) = 170 BVPs

20

30

50

70

Medium SmallMediumMedium High © 2016 Robertson Consulting Ltd Small

120

155

High Very High

200+ Just Do It!

Slide 64

* * Team ready to deploy to Operational state or Production * Commonly is built in to the Sprint Plan * Typical Activities are: * End-to-End Regression Testing * User Acceptance Testing * User Training * Operational Training * Operational Acceptance Testing * Knowledge Transfer to production/operations/support teams * Change management * Documentation completion * System Sign off and acceptance © 2016 Robertson Consulting Ltd

Slide 65

* √ Plan of Epic or Feature set evolution √ Decompose Themes and Epics to User Stories √ Estimate Story Points √ Determine Product Backlog Total Story Points √ Agree number of weeks per sprint √ Estimate initial Velocity of Development Team (1st Sprint) √ Estimate total number of Sprints required √ Match Epic and User Stories √ Create Release Plan with Milestones √ Update Release Plan after every Sprint Review √Ensure “Definition of Done” is documented Slide 66 © 2016 Robertson Consulting Ltd

*

Milestone Date

PRIORITISED PRODUCT BACKLOG

Epic (Feature set)

Large User Story

User Story

User Story

User Story

User Story

User Story

User Story

Epic (Feature set)

Epic (Feature set)

Large User Story

User Story

Milestone Date

User Story

Large User Story

User Story

User Story

Large User Story

User Story

User Story

Large User Story

User Story

User Story

User Story

Large User Story

User Story

User Story

Large User Story

User Story

User Story

Release 1 Sprint Zero

1

2


3

4

Epic (Feature set)

Large User Story

User Story

User Story

Large User Story

User Story

User Story

Release 2 5

6

Sprints (2-4 weeks each)

7

Milestone Date

8

Large User Story

User Story

Large User Story

User Story

User Story

User Story

Release 3 9 Slide 67

*

Milestone Date

Epic Location Facilities

PRIORITISED PRODUCT BACKLOG

Epic Location Choice

Large User Story

Us Us Use er User er r User Stor St Story Sto Sto y or ry ry y

Large User Story

UUU sss eee rrr SSS ttt ooo rrr yyy

Large User Story

Us Us er er St St or or y y

U s e r S t o r y

U s e r S t o r y

Release 1

Sprint Zero

1


U se r St or y

Epic Special Events Night

Epic Special Events Day

Larg e User Stor y

UU ss ee rr SS tt oo rr yy

Milestone Date

Epic Accommodatio n Choice

Lar Larg ge e Us Use er r St Stor or y y

Large User Story

La rg Lar e ge Us Us er er St Sto or ry y


UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy




Large User Story


Large User Story


Epic Travel to Location

Epic Travel at Location

Large User Story

Large User Story

Large User Story




Epic Have the Holiday!

Epic Bookings

Release 3

Release 2 2

Epic Accommodat ion Facilities

Milestone Date

3

Sprints (2 weeks each)

4

Slide 68

* *Focuses on: 1. The Sprint Goal 2. User Stories and their Acceptance Criteria * Confirming the User Stories are understood * Acceptance Criteria are clear and unambiguous * Confirming “Story point” estimates for User Stories

3. 4. 5. 6.

SCRUM MASTER

PRODUCT OWNER


Estimating effort required for identified Tasks Confirming sufficient resources and time Confirming Development Team’s commitment Confirming estimated Team Capacity/Velocity Slide 69


* * Product Owner:

* Defines the Sprint Goal/Objective * Offers the Sprint Backlog “candidates” * Clarifies questions * Explains Acceptance Criteria * Agrees final Sprint Backlog

SCRUM MASTER

PRODUCT OWNER


* The Development Team

* Creates and estimates tasks * Confirms estimated Velocity * Creates and commits to the Sprint Backlog * Confirms Definition of “Done”

* The Scrum Master

* Facilitates the meeting * Assists the Development Team with process * Determines what “Information Radiators” will be used Slide 70


* Monday Sprint Planning

Tuesday

Wednesday

Thursday

Friday

Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision






Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision • Story Time











Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision • DEMO Rehearsal

Sprint Review & DEMO


Sprint Retrospective

Slide 71

* * Collaborative * Self-organising * Cross-functional * Engaged & Focused * Daily Stand-Ups * Accountability * Empowerment * Conversations over Cards/Documents * “Please explain the Value that brings?” * Removing impediments

User Story

User Story

User Story


* *Something stopping or slowing us *Causes major inefficiencies and waste *Agile with Scrum handles impediments aggressively *General rule is 24 hours before Escalation *Championed by the Scrum Master


* Lean

XP Characteristics include: 1. To improve software quality and responsiveness 2. Advocates frequent "releases" in short development cycles 3. Other elements include: 1. Programming in pairs 2. Extensive code review, unit testing of all code 3. Avoiding programming of features until needed 4. A flat management structure 5. Simplicity and clarity in code 6. Expecting changes 7. Frequent communication 8. SW engineering practices taken to "extreme"


Scrum

Less Prescriptive

XP

More Prescriptive


* Activities: XP describes four basic activities that are performed within the software development process:

1.

Coding

Testing: Test-driven development – “if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws”.

2. Unit tests 3. Acceptance tests 4. System-wide integration testing Slide 75 © 2016 Robertson Consulting Ltd

* • Coding: • Customer always available • Code the Unit test first • Only one pair integrates code at a time • Leave Optimization until last • No Overtime • Testing: • All code must have Unit tests • All code must pass all Unit tests before release. • When a Bug is found tests are created before the bug is addressed (“a bug is not an error in logic, it is a test you forgot to write!”)

• Acceptance tests are run often and the results are published Slide 76 © 2016 Robertson Consulting Ltd

* Problem Statement

Does the Product/Service/Result solve the problem? Are all Requirements Requirements Satisfied?

Design

Does the Design Work?

Specifications

Acceptance Testing System Testing

Integration Testing

Unit Testing

BUILD Slide 77


D E P L O Y M E N T

* *Scrum Master and Development Team *15-20 minutes *Three questions: *What did you do yesterday? *What will you be doing today? *Are there any “Impediments”? *Problems/Issues solved later *Focused and engaged throughout

SCRUM MASTER



* *No tasks, No talk! SCRUM *Task - must attend MASTER THE DEVELOPMENT TEAM *No side conversations *Report to the Team *Taskboard and Sprint Burndown for discussion *New Tasks placed on the Taskboard *Scrum Master ensures Information Radiators are updated *Scrum Master deals with any Impediments *NB: Post Rules visibly Slide 79 © 2016 Robertson Consulting Ltd

* *Being late *Sitting down *Longer than 20 minutes *Dealing with problems – “solutioning” *Allowing “Chickens” to speak *Not holding people accountable *Side conversations


* 450

Cost Performance Baseline

Actual Costs

400

BAC

Cumulative Cost $K

350 300 250 200 150 100 50

0 SPRINT 0 SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5 Time Slide 81


* 400

Story Point Target

Story Points Not "Done"

350

User Story Points

300 250 200 150 100 50

0 SPRINT 0

SPRINT 1

SPRINT 2

SPRINT 3

SPRINT 4

SPRINT 5

Time Slide 82


* 30

Story Point Target

Story Points Not "Done"

25

User Story Points

20 15 10 5

0

DAY 1

DAY 2

DAY 3

DAY 4

DAY 5

DAY 6

DAY 7

DAY 8

DAY 9 DAY 10 DAY 11 DAY 12 DAY 13 DAY 14 DAY 15

Time Slide 83


* Sprint Backlog User Stories

Tasks To be Done

Tasks in Progress

Tasks for V&V (AC)

√

User Story

Tasks . 1… 2…

.

√ √

Tasks . 1… 2…

User Story

√ √

.

User Story .

User Story .

Tasks . 1… 2…

Tasks . 1… 2…

√


“Done” √

SCRUM MASTER


David

Phil

Thea

Simon

Slide 84

* * TRELLO (Free) * JetBrains You Track * Telerik TFS * Pivotal Tracker (Free Agile tool) * SeeNowDo.com (Free Taskboard) * Microsoft VSTS (TFS) * Mingle * Jira with Greenhopper plugin * Rally, VersionOne, Scrum works * TargetProcess * Leankit’s free Kanban Software (several platforms) * Others Slide 85 © 2016 Robertson Consulting Ltd

* * Product Owner and other Stakeholders * Demonstration by Team member * Facilitated by Scrum Master * Includes:

SPRINT REVIEW

* Demonstration * Report from Scrum Master

PRODUCT OWNER

SCRUM MASTER


Other Stakeholders

 What we intended to do  What was achieved – “Done”  The Delta and why

* Feedback * Customer Satisfaction

* 2-4 hours

(Approx 1 hour per week of sprint)


Slide 86

* * Objective:  Continuous improvement  Identify inefficiencies  Learn and adapt

SCRUM MASTER


* Scrum Master and Development Team * Must be “safe” * “Inspect and Adapt”, asking:  What worked well?  What did not work so well?  What and how will we improve?

* Scrum Master facilitates and captures “adaption actions” Slide 87 © 2016 Robertson Consulting Ltd

*

Slide 88

* Course References * “A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK TM GUIDE)”, 2013 Edition. Published by SCRUMStudy TM, a brand of VMEdu, Inc. ISBN: 978-0-9899252-0-4.

* “Agile Project Management with Scrum”, Ken Schwaber, 2004. Microsoft Press. ISBN: 0-7356-1993X

* “Scrum: A breathtakingly Brief And Agile Introduction. Chris Sims & Hillary Louise Johnson. Published by Dymaxicon. 2012. Kindle Version.

* “The Elements of Scrum”, Chris Sims & Hillary Louise Johnson. Version 1.01,2011. Published by Dymaxicon. ISBN: 978-0-9828669-1-7.

* “The Scrum Checklist”. Paul VII, published by Pashun Publishing, 2012. * “The Scrum Guide”. Ken Schwaber and Jeff Sutherland. Download free from Scrum.org. https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide.pdf#zoom=100.

* The Disciplined Agile Framework: A Pragmatic Approach to Agile Maturity - Published in the July/August 2016 issue of Crosstalk

* Going Beyond Scrum: Disciplined Agile Delivery (October 2013) * Scaling Agile Software Development: Disciplined Agility at Scale (May 2014) * The Disciplined Agile Process Decision Framework (January 2016) - Published in the 2016 Software Quality Days Conference Proceedings. © 2016 Robertson Consulting Ltd

Slide 89

* Course References * Project Management Institute, Practice Standard for Project Risk Management, 2009: PMI Publishing – ISBN 978-1-933890-38-8

* Project Risk Analysis and Management Guide, APM Publishing, 2004 – ISBN 1-90349412-5

* Drexler/Sibbet Team Performance Model, Grove Consultants International © 1999 www.grove.com

* Practical Software Estimation: Function Point Method for Insourced and Outsourced Projects. M.A. Parthasarathy. Addison-Wesley Publishers. 2007 - ISBN 0-321-43910-4

* PMI Website: http://www.pmi.org/Pages/default.aspx * SCRUMStudy Website: http://www.scrumstudy.com/


* Any Questions? 1. Wishing you every success with your future in project management and Delivering Projects using Agile with Scrum. 2. Feel free to reach out to me on Linked In https://uk.linkedin.com/in/simonrobertson 1. [email protected] 2. 07967 300344 (M)
