Agenda:

Scrum framework overview (30 min)

Hands-on Exercise (1.5 hrs)

Why Scrum?

• Faster time to Market (Release Early & Often)
• Respond and Encourage Change
• Smaller, Faster Failures
• Higher Stakeholder Engagement
• Higher Employee Engagement
• Higher Quality
• Higher Productivity
• Manages Risk & Change Effectively

Agile manifesto

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Roles

ScrumMaster

• Responsible for 'How'
• Owns Committed Sprint Backlog

Product Owner

• Responsible for 'What'
• Owns Product Backlog

Team

• 7+-2
• Cross-functional

Product Backlog

Owned by the Product Owner

Contains:

• Features
• Bugs
• Technical work (Example: install local environment)
• Knowledge acquisition (Example: research of a JavaScript library)

Sprint Backlog

Owned by the Scrum Master

• User stories committed to by the entire team
• Updated daily
• Reviewed during daily stand-up meeting

Scrum Framework

Burndown Chart

Scrum Meetings

Definition of Done (DoD)

• A checklist of activities that add value to the product
• Determine the workflow the team uses for the project
• DoD varies by team

Example DOD

• Story is developed/coded

• Story passed peer review

• Story tested by QA engineer

• Acceptance criteria are met and approved by product owner

• Code is promoted to staging environment and ready for demo

Sprint Length

• Ideal sprint length is 2 - 4 weeks

• We've found the best length is 2 weeks

• 1 week is too short; too many meetings and not enough development time

Planning Meeting

• Core scrum team attends this meeting

• Stories are ready before the meeting

• Product owner reviews goals and introduces each story

• Development team commits to story points to complete over the sprint

• Stories are moved to the sprint backlog

• Team discusses how to complete each story

• Each user story is estimated in points

• Subtasks are estimated in hours

Daily Standup

• Review the scrum board
• Only 15 minutes long
• What did you do yesterday?
• What are you planning to do today?
• Do you have any blockers?
• Scrum master notes any blockers and works to resolve them

Backlog grooming

• The core team attends
• Stories are prepared for future sprints
• New epics and stories might be added
• Acceptance criteria are written
• Initial pass at estimation before planning
• Outstanding questions or missing requirements addressed and documented

Sprint reviews

• All stakeholders attend
• Demo length is 1 hr. per each week of development
• Product owner introduces the stories the team worked on during the sprint
• A key person presents the work
• Schedule a script review the day before to walk through the presentation

Sprint Retrospective

• Scheduled after the demo
• Team walks through the sprint and discusses what went well, what needs improvement, and what the team should continue doing
• Feedback is captured in a template with clear action items
• Open issues are addressed and solved in the next sprint
• Review previous retrospective at the next one

Sprint schedule

Agile Requirements

User Stories

• Description of a feature, told from the perspective of the person or user that desires that feature.

​

• As a [type of user], I [want/need to/etc.] so that [some reason or benefit].
  • As a project manager, I want monthly invoices to include weekly hours so that I can quickly reconcile them against my own records.

Why User Stories?

User stories break large requirements into bite-sized pieces that are easier to digest, understand and build against.

• Written in plain english
• Demonstrates the value being added, but allows room to improve and iterate over time
• Small enough to allow for easier estimation and prioritization

Epics

Epics are generally just large user stories!

• Broad in scope
• Light on details
• Commonly split into multiple, smaller stories

As a registered user, I want to be able to manage my login credentials so that I can keep my account both secure and easy to remember.

Estimation

Estimation in Agile:

• Is a collaborative, team effort.
• Does not quantify work in terms of time.
• Uses relative effort and complexity to size stories.

Planning Poker:

• The product owner presents a short overview of the story.  The team asks questions.
• Every participant selects an estimate.
• High/low estimates give their reasoning.
• Repeat the process until a consensus is reached!

The Deal with Defects

• If acceptance criteria are not met, then those bugs must be closed during the current sprint in order for the story to be “done”

• Adding bugs into the current sprint without sizing them is the cleanest and most efficient approach

• The context is fresh for the development team so they’ll be quicker to fix

Handling Bugs in the Sprint

• Continuous focus on backlog economics

• Bugs are prioritized in the sprint backlog by the Product Owner

• Minor bugs can be moved to the backlog to be prioritized and estimated for future sprints

Q&A

Breakout Session

Hands-on Scrum

Organize Team (5 min.)

• 6 to a table
• Choose a scrum master

Project Charter (5 min.)

• Project overview
• Timeline
• Present vision
• Theme is a town in the 1800's.

Build the backlog (15 min.)

• Building the backlog
• Estimate stories
• Add to the sprint backlog

Estimating (20 min)

• Choose a sample size and assign a feature (for example, a one story building might be a 2)
• Teams will use planning poker cards to estimate

Planning (3 min.)

• Move sticky notes to product backlog
• Team decides which stories to put in the sprint backlog

Sprint! (7 min.)

• Build the features in your sprint backlog
• Move the stories through the swimlanes to reflect their status

Demos (5 min.)

• Each team presents their work to the product owner

Retrospective (3 min.)

• Discuss how to improve the process for the next sprint

Debrief

• What did you observe?
• How accurate were the estimations?
• What would we have done differently from the beginning, if we had another chance to play the game?
• What was the job of the Product Owner?
• How did it feel after the first sprint when almost all items required re-work?
• What did the Scrum Masters do?
• How will your strategy change, if you know the Product Owner is unavailable during sprints?
• How did inter-team communication go? Were there any dependencies? How were they resolved?
• What did you learn?