Agenda:

Scrum framework overview (2 hrs)

Breakout sessions (2 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

Sprint Backlog

Scrum Framework

Burndown Chart

Scrum Meetings - Jenna

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?

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

Sprint schedule

Agile Requirements - Kenneth

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

Drew

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 in the Sprint

  • Continuous focus on backlog economics

  • Bugs are prioritized in the sprint 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?

Jira Workflows

Scrum planning board

Scrum Sprint Board

Kanban board

Scrum Report board

Q&A

Breakout Session 1

Hands-on Scrum

Organize Teams (5 min.)

  • 6 to a table
  • Choose a scrum master

Project Charter (10 min.)

  • Project overview
  • Timeline
  • Present vision
  • Theme is London, 2084

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?

Breakout Session 2

Product Owners

  • How do we help clients become good product owners?

  • How can we split the product owner role with clients to ensure the process and project runs smoothly?

  • How do we handle a project when everyone at the client is the product owner?

  • What happens when we have no product owner (or one that is not involved)?
Made with Slides.com