Waterfall

Agile manifesto

Scrum

Good for teams working toward milestones and deliverables

Timeframe and effort based

Kanban

Good for teams with small tasks and tight turnaround (Ops, e.g.)

Issue count based

How does SCRUM help?

• Breaking a vision statement into small chunks
• Scope (i.e., Features) is what's flexible
• Testing happens in each cycle, instead of at the end

The goal is not to do as many tasks as possible. The goal is to have as great an impact as possible by doing as few tasks as possible.

- Agile Manifesto Principles

scrum
Roles

Product owner

Responsible for the Product and the Development team

The sole person responsible for managing the Product Backlog

Development Team

Cross-functional, with all of the skills as a team necessary to create each increment

7 (+/-2) people, typically

Wait, what aboutme?

Vision

Roadmap

Release

Sprint

Day

yearly or more

biannual

quarterly

bi-weekly to monthly

daily

Five levels of Agile planning

Vision

The broadest picture you can paint of the future.  

Further planning will detail the vision & may divert from the vision because the future will bring us a changed perspective. 

Roadmap

• Communicate the whole picture

• Determine and communicate when releases are needed

• Determine what functionality is sufficient for each release

• Focus on business value derived from the releases 

Release

Used when there are multiple teams with dependencies.

• Planned around fixed release dates, themes, and feature sets
• Requires prioritized, rough estimated backlog
• Planning by Product Owner and whole dev team
• Works well to link to a minimum viable product* release

Sprint

Creating a “Done”, useable, and releasable increment.

• Based on prioritized backlog & the individual teams' capacity

• Sprint Goal: objective that will be met, why the team is building this increment​

• Daily Planning is part of the Sprint*

The
Backlog
 

The backlog

an ordered list of everything that might be needed for the product

Product Owner is solely responsible for it

Dev Team provide rough effort estimates for everything on the backlog 

Smaller, broken down issues to work on first, huge generic ones further away

Primary issue type is something called a User Story

(IS EVERYTHING)

User Story

a plain English, first person description of a feature

"As an [Email User], I want to [Archive Messages] so that [my Inbox isn't crowded.]"

User stories continue to get refined into more and more discrete chunks as you get closer to the point when you have to build that feature.

Good USER STORIES require investment

•  Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

SPACESHIPS!

Estimates!

Humans are terrible estimators

estimate effort

• No assumption of accuracy
• Fewer options, like simple numbers or T-Shirt Sizes 
• Easier to compare to stuff you've done before

Instead of estimating hours,

Story Points

1, 2, 3, 5, 8, 13, 20

A really rough numerical scale for estimating effort on User Stories

Numbers get wider apart the more effort something takes to accept that stuff takes longer

Bigger items need to get broken down into smaller chunks

Developers only

Only developers get to estimate how much effort something is.

• If I'm not actually building it, I don't get to tell you it's "so simple, just do it, just do it, it's easy"
• All developers should agree on the estimates
• Effort includes all the steps to reach "done"
  • Development
  • Local Testing
  • Code Review
  • Quality Assurance
  • User Acceptance Testing

The
sprint

What's in a sprint?

• Sprint Planning

• Daily Scrums

• the development work

• Sprint Review

• Sprint Retrospective

Sprint planning

A meeting before each new sprint

What can be delivered this sprint?

Product Owner discusses objective and backlog items that would achieve it

How will we get it done?

Development team forecasts what it can do in the upcoming sprint

Break down stories into sub-tasks of no more than a day or two for the first things you plan to tackle

Daily Scrums

A max 15-minute daily meeting for dev team and Product Owner

Three questions to answer:

• What did I do yesterday?
• What will I do today?
• Do I see any impediment or blocker?

Often followed by more detailed discussions amongst team members to adapt or re-plan

Sprint Review

Informal at the end of the sprint

Includes dev team, product owner, stakeholders

• Explain what has been done and not done
• Demo the work that is done, answer questions
• PO discusses current backlog, perhaps rough projections
• Entire group collaborates on most valuable to do next

Result is a revised backlog to help plan the next sprint

Retrospective

Before next Sprint Planning

Includes dev team, product owner, scrum master

Meant for team to provide self feedback and establish process improvements

so many
Meetings!

It sounds much worse than it is.

Focus is talking with each other during development, not about the number of meetings you have.