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