* 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
© 2016 Robertson Consulting Ltd
* Multiple External Stakeholders
Multiple Internal Stakeholders
Single Organisation
Operational Projects
Product/Process Development Projects
Technology/ Platform Development Projects
© 2016 Robertson Consulting Ltd
Classic
Classic
Classic/Agile
Classic/Agile
Classic/Agile
Agile
Classic/Agile
Agile
Agile
* THE AGILE UMBRELLA
SCRUM
XP
Less Prescriptive AUP Crystal Clear
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
*
Slide 9
© 2016 Robertson Consulting Ltd
*
Slide 10
* * Sprint Planning * Sprint Backlog * Product created and tested * Daily Scrum * Backlog Revision * Sprint Review * Sprint Retrospective
Slide 11 © 2016 Robertson Consulting Ltd
* * Product Owner * Scrum Master * The Development Team
PRODUCT OWNER
THE DEVELOPMENT TEAM SCRUM MASTER
Slide 12 © 2016 Robertson Consulting Ltd
* 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
© 2016 Robertson Consulting Ltd
Adapted from the SCRUMstudy TM. “A Guide to the Scrum Body of Knowledge (SBOK TM Guide)”
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
Slide 17 © 2016 Robertson Consulting Ltd
* *Business Analyst *Architect or Architectural Owner THE DEVELOPMENT *User Experience Consultant (Ux) TEAM *Developer *Tester *SME – other Subject Matter Experts as required *Others?
Slide 18 © 2016 Robertson Consulting Ltd
* * 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
© 2016 Robertson Consulting Ltd
Adapted from the SCRUMstudy TM. “A Guide to the Scrum Body of Knowledge (SBOK TM Guide)”
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
Slide 20 © 2016 Robertson Consulting Ltd
* * 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
Slide 21 © 2016 Robertson Consulting Ltd
Adapted from the SCRUMstudy TM. “A Guide to the Scrum Body of Knowledge (SBOK TM Guide)”
* *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
THE DEVELOPMENT TEAM
KEY STAKEHOLDERS
PRODUCT OWNER
SCRUM MASTER
THE DEVELOPMENT TEAM
PRODUCT OWNER
SCRUM MASTER
THE DEVELOPMENT TEAM
Slide 23 © 2016 Robertson Consulting Ltd
* 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
Slide 27 © 2016 Robertson Consulting Ltd
*
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
© 2016 Robertson Consulting Ltd
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
THE DEVELOPMENT TEAM
* 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
THE DEVELOPMENT TEAM
Slide 31 © 2016 Robertson Consulting Ltd
*
Slide 32 © 2016 Robertson Consulting Ltd
* 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”
Slide 34 © 2016 Robertson Consulting Ltd
* * 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
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
*
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
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
* * 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
© 2016 Robertson Consulting Ltd
*
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
© 2016 Robertson Consulting Ltd
*
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
© 2016 Robertson Consulting Ltd
* *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
.
.
© 2016 Robertson Consulting Ltd
.
.
Slide 45
* *U – nderstandable * I – ndependent *N – egotiable *V – aluable *E – stimable *S – imple *T - estable
User Story
User Story
User Story
User Story
.
.
.
.
Slide 46 © 2016 Robertson Consulting Ltd
* * 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 .
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
* *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?
Slide 51 © 2016 Robertson Consulting Ltd
* * 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
Slide 54 © 2016 Robertson Consulting Ltd
* *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
Slide 56 © 2016 Robertson Consulting Ltd
* *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
© 2016 Robertson Consulting Ltd
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.
Slide 60 © 2016 Robertson Consulting Ltd
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”
Slide 61 © 2016 Robertson Consulting Ltd
* * 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
© 2016 Robertson Consulting Ltd
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
© 2016 Robertson Consulting Ltd
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
UU ss ee rr SS tt oo rr yy
UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy
UU ss ee rr SS tt oo rr yy
UU ss ee rr SS tt oo rr yy
UU ss ee rr SS tt oo rr yy
Large User Story
UU ss ee rr SS tt oo rr yy
Large User Story
UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy
Epic Travel to Location
Epic Travel at Location
Large User Story
Large User Story
Large User Story
UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy
UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy
UUUUU sssss eeeee rrrrr SSSSS ttttt ooooo rrrrr yyyyy
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
THE DEVELOPMENT TEAM
Estimating effort required for identified Tasks Confirming sufficient resources and time Confirming Development Team’s commitment Confirming estimated Team Capacity/Velocity Slide 69
© 2016 Robertson Consulting Ltd
* * 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
* 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
© 2016 Robertson Consulting Ltd
* 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
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
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
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
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
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
Daily Stand Up • Dev Team Execute • Product Owner PrePlanning and Backlog Revision
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
© 2016 Robertson Consulting Ltd
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
Slide 72 © 2016 Robertson Consulting Ltd
* *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
Slide 73 © 2016 Robertson Consulting Ltd
* 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"
© 2016 Robertson Consulting Ltd
Scrum
Less Prescriptive
XP
More Prescriptive
THE DEVELOPMENT TEAM
* 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
© 2016 Robertson Consulting Ltd
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
THE DEVELOPMENT TEAM
Slide 78 © 2016 Robertson Consulting Ltd
* *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
Slide 80 © 2016 Robertson Consulting Ltd
* 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
© 2016 Robertson Consulting Ltd
* 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
© 2016 Robertson Consulting Ltd
* 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
© 2016 Robertson Consulting Ltd
* 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…
√
© 2016 Robertson Consulting Ltd
“Done” √
SCRUM MASTER
THE DEVELOPMENT TEAM
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
THE DEVELOPMENT TEAM
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)
© 2016 Robertson Consulting Ltd
Slide 86
* * Objective: Continuous improvement Identify inefficiencies Learn and adapt
SCRUM MASTER
THE DEVELOPMENT TEAM
* 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/
Slide 90 © 2016 Robertson Consulting Ltd
* 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)
Slide 91 © 2016 Robertson Consulting Ltd