Regan Davis

VP of Product Management
Jellyvision

Makers of ALEX, an interactive conversation for explaining HR and benefits to employees

Clients include Facebook, Disney, IBM, & HP

 

Previously VP of Product at info.com & Zenya

Everything is awesome

So many fantastic ideas to build

Sadly, none of them is a time machine

Waterfall

Everything is locked in up-front

Teams spend months designing, architecting, developing

Right before completion, pieces are put together and tested

 

Agile

Plan enough to do meaningful work, light planning for far off vision stuff

Short, repeated releases that are tested each time

Feedback from the customer throughout, so you can change the plan as needed

 

At the very end, it’s presented to the customer, who of course, loves it and says it’s exactly what they always wanted.

How does Agile 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

Good for teams working toward milestones and deliverables

 

Timeframe and effort based

Kanban

Good for teams without distinct deadlines (Ops, e.g.)

 

Issue count based

Why

Iterate?

scrum
Roles

Product owner

Development Team

Scrum Master

Responsible for ensuring process is understood and enacted

Exists to protect the development team and the process

Wait, what aboutme?

Vision

Roadmap

Release

Sprint

Day

yearly or more

biannual

quarterly

bi-weekly to monthly

daily

Five levels of Agile planning

The
Backlog
 

The backlog

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

 

 

(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.]"

 

 

Refine and Break Up as You Go

As A User...

User Story

As a user who chose an HDHP medical plan, I want to see my tax savings with an HSA, so that I can contribute to an HSA.

 

Acceptance Criteria

  • Pulls estimated OOP costs from medical recommender
  • Applies federal tax + FICA tax % (if not asked, use 19.65% average)
  • Shows $ savings from contributing to HSA (OOP-tax%), and breaks OOP costs contribution by paycheck
  • Ask to contribute. Options: "Yes", "I'm not ready yet"
    • If "Yes", apply to plan selection
    • If "I'm not ready yet", Send to Tax Savings module

Good USER STORIES require investment

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

OH YEAH It's An  Estimate pArty!

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

 

Death to All time estimates!

Yes and No.

 

Some places still prefer hour-based estimates

Hour estimates can still be good to break down components of a Story in Sprint Planning

 

 

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.

Questions?
 

Made with Slides.com