Agenda

Scrum framework overview

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

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

Scrum Framework

Roles

ScrumMaster

  • Responsible for 'How'
  • Owns Committed Sprint Backlog

Product Owner

  • Responsible for 'What'
  • Owns Product Backlog

Team

  • 7+-2
  • Cross-functional

Product Backlog

Sprint Backlog

Burndown Chart

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

  • How long are your sprints?

Scrum Meetings

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

  • View 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

Demos (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 (if PO is involved)
  • A key person presents the work
  • Schedule a pre-demo review the day before to walk through the presentation
  • What challenges do you face with demos?

Example Demo Script

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 retro at the next one

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!

Common Headaches

Subtitle

Scrum + Fixed Price?

Scrum typically works best in a time and materials model, but can still be used for projects with fixed price and fixed scope.

 

How do we manage this?

Fixed-bid induces headaches

  • High risk for all parties regardless of methodology
  • But...
    • Agile focuses on highest value delivery
    • Agile provides earlier insight than Waterfall
    • Resulting in more options and friendlier "uh oh" conversation
    • Retain better client relationship

Agile/FP Best Practices

  • Really, really set client expectations
  • Have a Discovery Phase
  • Have a Sprint 0
    • Build out Product Backlog

  • Have all of the requirements for a user story ready

  • Swap out stories of equal value

  • Negotiate change requests

  • Run a tight ship

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 so they’ll be quicker to fix

Handling Bugs 

  • Continuous focus on backlog economics

  • Bugs are prioritized in the product backlog

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

    What do your teams do?
    What challenges do you have?

Q&A

Made with Slides.com