How to be Productive

• A prioritized list of user stories
• Not tasks, like coding or meetings
• Prioritized by user or business goals
• Show priorities with ordering not numbers.
  • Top means "we do this next"
  • Not top means "we may never get to this"
  • Don't assign numbers or labels like "must-have".
    • Everything becomes "must have".

• Something new in the app that the user needs or wants
• Often written in the form "as a [type of user] I want [feature] so that I can [goal]"
• More important than form is impact on the user. No tasks in the backlog should lack user impact.

• A visual view-controller of the user stories for this iteration
• Ideally, a physical board in a shared team space
• Alternatively, an online visual tool like Trello and or Github project boards.

• Move stories move from left to right until completed
• Clear board and start over on each iteration
• Limit work in progress
  • If two stories in Doing, help a teammate finish one rather than start a new one
  • How to stuff envelopes

• You have an iteration backlog of user stories
• You have a team of developers
• You assign stories to each developer
• This is a bad idea.

• Assignments are made at a time of least information
• Everyone assigned a task becomes a potential bottleneck
• Tasks are owned by a person not the team
• Assignments encourage silos and low bus factor

• Put prioritized tasks in the Ready to do column
• When starting a coding session, pick whatever task is on top
• Start a feature branch, tell the team
• If you can't finish, throw away the branch
• Don't Push. Pull Work Items for Better Results

• No waiting for someone else to finish anything
• Forces everyone to be ready to code any part of the app
• Eventually everyone works on everything
• Team ownership of code increases

• "I don't know how to do the top task!"
  • The tests for Done are bad, or
  • The team has a bus factor problem
• "I can't do the top task alone!"
  • Why are you working alone?
  • The team's stories may be too big.

• If you can't commit code, throw it away.
• Never commit broken code.
• Don't keep branches open for multiple sessions.
  • Long-lived branches are bottlenecks and sources of integration failure.
  • Every re-entry takes times and risks forgetting something.
  • Reconstruction usually create simpler solutions.

• Learn how to slice:
  • Example: to move email column from user table into separate table
  • Create, test, and commit code for new email table, not integrated into app code
  • Create, test, and commit code to redundantly add new / changed emails to both user and email table
  • Create, test, and commit code to get emails from new table
  • Create, test, and commit changes to delete email column from user table

• Main branch always deployable
• Make feature branches for multi-step changes, e.g., a user story
  • Should last only a day or two
  • When done, merge with main and delete
• With client, create a long-lived development branch
  • Make feature branches off of development
  • Synchronize main and development weekly
  • Development always ready for user testing

<More to come!>

Thanks to Hakim El Hattab for RevealJS