A Primer on Agile/Scrum

This is a primer on the ideas/ls of Agile. They are not what most people think they are, and it would behoove many people to take time to learn what they really say.

The 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

Declaration of Interdependence:

We …

  • Increase return on investment by — making continuous flow of value our focus.
  • Deliver reliable results by — engaging customers in frequent interactions and shared ownership.
  • Expect uncertainty and manage for it through — iterations, anticipation and adaptation.
  • Unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • Boost performance through — group accountability for results and shared responsibility for team effectiveness.
  • Improve effectiveness and reliability through — situationally specific strategies, processes and practices.

Other types of Agile other than Scrum:

  • XP (Extreme Programming) – Focused on partner-programming and deep code reviews
  • TDD (Test Driven Development) – Focused on, well, TDD

Scrum – A type of Agile

  • Transparency – Visibility to people responsible for outcome
  • Inspection – Regularly assess how doing related to goals 
  • Adaptation – change process to fix problems

Defined By: 

  • Do just enough prep before starting work to be able to the work
  • Short sprints, 2-4 Weeks
  • Customer (The Business) must talk with the developers regularly

Team needs:

  • Product Owner – The business rep, maximizes value from sprints
  • Scrum Master – Process owner, ensures SCRUM is followed
  • Dev Team – Everyone on dev team is equal, there are no bosses, though people can work on specific things.


  • Sprint Planning Meeting
  • Grooming (technically not a formal Scrum event)
  • Daily Scrum (Standup)
  • Sprint Review – PO and Scrum team and customer meet to demo
  • Retro – Team assess selves


  • Product backlog – all work to be done to deliver full product
  • Sprint backlog – work to be done in single sprint – highest value items first
  • Product Increment – Part of overall product that can be released to customers on its own

Fail Fast => Learn Quickly

It’s ok if people make mistakes if they were trying.  The point is for us to do so early before we build lots on top of the broken.  We need to trust each other.  We don’t blame people for mistakes, we are a team, they are team problems, not individual problems


Definition of “Done”

Sprint Goals – Should be very visible and reviewed often – make sure you meet them

Burn down – Shows work as it gets completed

Burn up chart – Should how us when the product will finish, based on what is in backlog and velocity

Team makes its own rules, solves its own problems.  

Team makes its own definition of “done” – It’s the TEAMS decision if QA should be removed from the “done” requirement


The team should be inspecting what they are doing to see if it is working, and change their processes if they are not.

All Scrum events are opportunities to analyze your process and refine it.  

Value Driven Delivery

This is the POINT of Agile – Focus on Value

Product = Value

Value to Customers

What gives most value to customer?

Vertical slicing

Itemize each valuable deliverable

Defining Value

Requires Defining Value – Acceptance Criteria

Agreeing up front – helps minimize waste


Short Sprints

Short sprints allow you to fail faster.

2 week sprints you fail much faster than 4

Short sprints also show value to stakeholders more often 

Team Size

Team has 5 – 9 people 

Dev team specifically is 3-9 people

Then you need a PO and Scrum master

Up to 12, but that gets to be a challenge, anything beyond that needs to be broken into multiple teams.

Multiple Teams

Scrum of Scrums

With multiple teams, Scrum masters from each team meet 2-3 times a week to coordinate efforts between teams.

Scrum Events:

Events should be timeboxed based on the length of sprints.  If you have longer sprints your events will need to be longer – except Daily Scrum, which is always 15 minutes.

Sprint Planning:

Every sprint should create a working product increment.

What is needed for Sprint Planning Meeting:

  • The Backlog needs to be ordered
  • Items completed in last sprint
  • Velocity of team
  • Dev Teams capacity (is anybody on vacation?)
  1. What can we do that will result in a product increment?
  2. How will we do it?

PO provides a list of possible items for sprint and Dev Team decides which ones to accept, with the mind toward creating a working product increment.

Sprint Goal is defined:

Sprint goal is: Summary of the work and the value that will be delivered in the product increment.

Daily Scrum (standup):

The daily Scrum (also known as standup) is a daily, timeboxed 15 minute meeting, where everyone on the team goes of:

  • What they did yesterday
  • What they are doing today
  • Any roadblocks

Scrum Guide Says:

  • Scrum Master does NOT attend Daily Scrum, they only ensure it happens.
  • The Product Owner ALSO does not attend the Daily Scrum.

Scrum Alliance Says:

  • Entire Scrum Team Addends
  • Any member can provide updates

Team members can meet after Daily Scrum to talk about things that came up.

Backlog Refinement:

This is an ongoing process where the PO gathers information needed for items in the backlog.

ALSO: Backlog Refinement can be a meeting after the midpoint of sprint.  Inspect backlog items and dev team asks for clarification on things targets for next sprint.  Sounds like Octopus Grooming. Scrum Guide does not have this meeting, but Scrum Alliance does.

How to tell if item is ready for a sprint:

  • Sized small enough to fit in a sprint
  • Dependencies are identified and managed
  • Acceptance Criteria has been defined

Sprint Review:

This is the inspect and adapt event for the Scrum team and all the key stakeholders.  Product increment is the subject of the event.  This is the second to last event in the sprint.  Usually held in the afternoon to give the morning to finalize anything. Questions from stakeholders are encouraged!  Timeboxed meeting.  Probably 2 hours.

Things gone over:

  • PO gives sprint goal and issues worked
  • Demo
  • PO goes over issues in next sprint
  • Open discussion with stakeholders – capture feedback
  • Turns feedback into backlog issues



The point is to demonstrate value to Stakeholders.

Stakeholders need to be at demo!

It is their opportunity to give feedback

Timing demos is important.

The higher the risk the more often you should demo.

Customer feedback need for quality

You can even demo every week instead of at the end of sprints OR Every other sprint!

They do not have to follow the sprints

More often = more informal / less often= more formal

Might make sense to demo before releases, not with sprints

Sprint Demo

Demos the stories completed in the sprint

PO or Devs can demo, then stakeholders give feedback or missing requirements (those are hopefully stories further down the backlog, but might need new stories.)

Product Demo

Show stakeholders the collective product as it is being built

This is a demo that gives a cohesive view of what the product looks like

This should be done for every release

Sprint Retrospective:

Focused on Scrum team.  This meeting is about how the team can make improvements for themselves and their process.

Things to review:

  • What went well – consider why they went well and how to keep momentum going
  • What didn’t go well – why didn’t they go well and how can we improve that

Then look at both lists and decide what to focus on in next sprint – you should only pick 2-3 ites to work on in the next sprint, or it will become too much.  These need to stay visible to team through sprint.

Release Need to be Valuable:

MVP – Minimum Viable Product

MMF – Minimum Marketable Feature


MVP Advantage – 

  • Feedback sooner
  • Early ROI

Backlog Prioritization

Backlog MUST stay prioritized with what the customer values most as the highest priority

It is the PO’s responsibility to organize the backlog – But they get their demands from the stakeholders.

The backlog exists as long as the product exists.

Items in the backlog are Product Backlog Items, or PBIs

Backlog contains:

  • Features
  • Functionality
  • Requirements
  • Defects
  • Enhancements

Prioritization Options:


  • Exciters
  • Satisfiers
  • Dissatisfies
  • Indifferent Features


  • Must Have
  • Should Have
  • Could Have
  • Would like to Have

Lots of other ways you can do it too.

Sprint Backlog:

Subset of backlog with the items that are to be completed in the sprint.

The Dev Team NOT the PO decides what is to go into the Sprint Backlog.  This is because the goal is to create a working product increment, and the Dev Team is best suited to identify what PBIs can create a working product increment. 

Decision Making

Everyone is involved in decision making, and you are looking for convergence, team and stakeholders.

Agile Charter

Focuses on project goals, not what will be built.

  • Who will be engaged in project?
  • What will the project be about?
  • Where will the work happen?
  • When will the work happen?
  • Why was the project needed?
  • How will you work?

Need Vision

Need Definition of “Done”

Agile Modeling

Ways to model things, and get feedback from stakeholders – Should be used every time you start work on new valuable deliverables

  • Diagram use cases
  • Model data structures
  • Sketch screen designs
  • Wireframe
  • Personas – User use description

Status updates

Status reports suck – don’t use them

There are the charts (burndown, etc.)

Need to have conversation with stakeholders

What to Communicate

  • Charter
  • Vision
  • Sprints
  • Release Plan
  • Burn Charts
  • Project Risks
  • Quality/Defect stats

Forecasting short term results is a lot easier than long term (duh)

Product Demo

Show stakeholders the collective product as it is being built

This is a demo that gives a cohesive view of what the product looks like

This should be done for every release.

Adaptive Planning

Constant planning – planning to plan

You are planning every day.

Everything is planning.

Progressive Elaboration

Incorporating new information into plans to reprioritize backlog.

Every time you release an MVP you need to reevaluate all of your previous plans – did the process change any of your plans?  This should be a big meeting with stakeholders where everyone gets to have input on how priorities have changed.  Then the backlog will need to be reprioritized. 

Possible Additions

Iteration 0 (Sprint 0)

Iteration 0 an option addition that is basically a sprint before the first sprint that allows you do to things such as:

  • Identify resources
  • Setup workspaces
  • Setting up environments
  • Establishing a vision
  • Early planning
  • Hiring
  • Training

Doesn’t have to be length of full sprint

Iteration H (Hardening Sprint)

Hardening, finalizing, testing, documenting –  before product moved to production

Architectural Spike

Short (like 1 week) while team investigates PoC

Risk-Based Spike

Used to test new-untested technology

Relative Sizing

Used because people are better at comparative sizing than actual sizing

Fibonacci – follows normal growth patterns and normally used

Estimation Techniques

Wideband Delphi: Team anonymously submit estimates to avoid bias (not actually used much)

Planning Poker: Most widely used (would have to research)

Team Roles:

Role: Project Sponsor

Usually senior leadership and not directly involved day-to-day

  • Main Project Advocate
  • Final Decision Maker

Role: Product Owner

Soul accountable party for the product the team is building.

Should be a person from The Business.

Need to be able to answer Dev Team questions.

Need to be able to negotiate backlog items.

Must be able to talk with other people in business.

Makes the decisions about product vision and the features that are needed.

Represents stakeholders.  

Dev team only takes orders from PO.

Responsible for maximizing value.

PO -AND ONLY THE PO- manages the backlog.

A proxy can be used if the PO can’t dedicate the full time – but the PO is ultimately responsible. 

A Business Analyst can work with the PO to help them prioritize for the business.

Though the PO is responsible for the backlog they can delegate responsibility to parts of the Dev Team, especially in the case of technical issues they don’t understand.  

PO Responsibilities

  • Clearly define Backlog issues
  • Order/Manage Backlog
  • Ensure Backlog is available to the team, and across the Business.
  • Clarifying requirements
  • Providing status and forecast

PO Can abnormally terminate a sprint early – usually done when current work is found to have no value, and should be stopped.

PO does NOT manage the team – only the backlog

Role: Scrum Master

NOT the manager of the team

They manage the Scrum process, NOT the team

They instruct everyone – Dev team, Product Owner, Business – on Scrum process

They are the SERVANT of everyone

  • Protects team from outside distraction
  • Protects team from overcommitting
  • Protects team from complacency – makes sure team keeps refining and improving their process
  • Owns the Scrum framework – They are the ones who actually decide how/if process can be changed

Scrum Master’s Jobs

  • Clarify Goals and Objectives
  • Coach Best Practices
  • Guide Process and Planning
  • Facilitate Scrum Events
  • Share Knowledge

SM has their own Scrum event – Product Backlog Refinement

Role: Development Team

  • Builds product

Role: Stakeholder

Who are the stakeholders?

PO, Scrum master, team, and sponsor – brainstorm on this is.

Who are direct users of the product?

Executives, manager, who in the company?

The stakeholders need to be told about Agile.

They need to be present in demos.

Definition of Done

The Definition of Done is something that should constantly be reviewed.  This is different from the Acceptance Criteria of a PBI, ACs are different for different PBIs, DoD is across the board for all PBIs.  Teams should have a defined definition of done for all PBIs, and constantly be reviewing it. Possible DoDs include:

  • Unit tests written
  • Reviewed by another developer
  • Passes linting

Team Norms

Ground rules created by team to guide the project and how team members interact.

Norms should be reviewed and updated every couple months – maybe after every MVP goes live?  Should spend an hour in a norming session. 

Possible rules:

  • Silence means consent – if you disagree, speak up
  • No meetings before noon on mondays, or after noon on Fridays
  • All opinions and ideas will be considered equally and thoughtfully
  • Team members will ask for help as soon as they know they need it
  • Team members will keep commitments to each other
  • Team members will hold each other accountable for maintaining norms
  • People will talk respectfully and thank each other for contributions
  • No devices in meetings without team consent
  • All decision made by consensus
  • Agree to try to resolve conflicts inside of team before going outside of team


Though everyone should have specific skills, team member should have general skills too, to be able to help with other tasks


When team members use secondary skills to help reach the sprint goal.

Collaboration and Commitment

The space you are in can include:

  • Product Vision
  • Task Board
  • Design Models
  • Burn down
  • Burn up
  • Team Norms

No reason we should be looking at things like burndown during the standups

When co-located, things like standups twice a day might make sense


Usually takes 3-4 sprints to get an established velocity.

Calculating: total points done / number of sprint = velocity

Can be used to calculate how much longer project will take


Can have brainstorming meeting about risk:

Goal to just ID possible threats

Assess how likely to happen, and how bad it will be if it does

 Should be considering risks in planning meetings

Risk Register

  • Owner of Risk
  • Mitigation Plan
  • Escalation Path – where does owner go if they need help


Agile is based on Kaizen (hey my mom did that in the 90s!) 

This means improving the quality of the work by making small adjustments over time

The Retrospective is a clear use of this idea. It is asked:

  • What went well?
  • What can be improved?
  • What can be done differently to improve? 

Growing Skills

  • Pair Programming
  • Skill Shares
  • Encourage continuous learning


A way to identify and eliminate a system’s waste without affecting productivity.  

Adapted from manufacturing.

  • Partially done work
  • Extra processes
  • Extra features
  • Task Switching
  • Waiting
  • Motion
  • Defects

Value Stream – The path a new idea has to go through to get to the customer

This should be mapped out, and you can then see where you can make it better

You can map any processes Value Stream –  like deployment process, and see where the problems are.