Skip to content

Latest commit

 

History

History
102 lines (66 loc) · 3.08 KB

WORKFLOW.md

File metadata and controls

102 lines (66 loc) · 3.08 KB

Workflow

It's hard to make great products. It's hard because there are a million choices along the way, and because it never really ends. In a word, it's uncertain.

There are two ways to deal with that; to control it, or to accept it.

The natural thing to do is to control it, and it works really well if you can predict the future. Otherwise it is futile, and you should not try.

The other way is to accept that it is uncertain and deal with it. That is to accept that things will change along the way, and to make it as painless as possible when they do.

That's called "agile", and that's what we choose to do.

Agile

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

-- Agile Manifesto

Our products vary in complexity and duration and so our workflow varies equally, but there are some things that we always do:

Stories

We keep things simple so everyone can contribute, and that starts with explaining things simply. When we decide what we're building, we describe it in short stories that explain who, what and why.

Good:

  • As a visitor, I want to log in with Facebook so that people can see who I am.

Bad:

  • Implement Facebook Connect with the JavaScript SDK.

Further reading on the making of good stories:

Stand-up

Every day, we tell each other what we're doing. We call it a stand-up.

We like to timebox stand-ups to 10 minutes where everyone takes turns asking these questions of themselves:

  • What did I do yesterday?
  • What will I do today?
  • Are there any impediments in my way?

Backlog

We keep a list of the stories that we should do, and we call it the backlog.

Sprints

Every week, we select the most important stories from the backlog to work on. We call that a sprint.

Sprint planning

At the beginning of each week, we get together to plan a new sprint. At the end of the meeting, the team should have committed to a week's worth of stories to complete.

We like to timebox sprint plannings to 30 minutes with the following agenda:

  • What are we doing next week?

Sprint review

At the end of each week, we get together to review the sprint that we had and to agree that the stories in it are in fact complete. At the end of the meeting, the stories that were completed are deployed, and the ones that aren't go back to the top of the backlog.

We like to timebox sprint reviews to 30 minutes with the following agenda:

  • What did we do last week?

Sprint retrospective

At the end of each week, we get together to talk about how we worked. This is how we get better.

We like to timebox sprint retrospectives to 15 minutes with the following agenda:

  • What should we start doing?
  • What should we stop doing?
  • What should we continue doing?