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?
Made with Slides.com