0%

An Agile Cheatsheet

Posted on Edited on In

A short “so you want to do Agile” cheat sheet.

Edit: Since I wrote this, I’ve gotten Scrum certified (PSM), so I’m in the process of updating my recommendations. Also, I’ve been reviewing Kanban practices as a possible better fit for technical development (especially in continuous integration environments), and non-technical environments with workflows that don’t seem like a fit for the timebox model of Scrum.

The Sprint Process

Do as a one time act. Put your planning board together

  1. Create master task list, aka ICEBOX.
    • New work can only enter through the ICEBOX.
  2. Rough task estimation.
  3. Break into themes:
    • EPICS: cards in a set amounting to more than a single feature or attribute, usually more than one sprint of work
    • STORIES: within epics, clusters of cards that are basically features or other concrete deliverables that can be completed within a single sprint, 1-2 weeks.

Do weekly (or bi-weekly) at start of SPRINT:

  1. Identify cards amounting to about a week or 2 weeks tasks from your planning board. Try to grab complete STORIES.
  2. Put cards in the TODO column of the SPRINT.
  3. No new work should enter the SPRINT while it is underway. New work or discovered always enters the ICEBOX and is reviewed for assignment at the end of a SPRINT

Do daily:

  • A short, daily check-in. ONLY 3 things discussed per person in 5 minute daily meeting:
    1. What was done since yesterday. (move DOING card to DONE. 1st day, there are no DOING cards). “What did I do yesterday?”
    2. What we plan to do by tomorrow. (move TODO card to DOING column, or move BLOCKED card to DOING column) “What am I going to do today?”
    3. What are blockers, if anything. (move DOING cards to BLOCKED column). “Are there any blockers?”

Do weekly at the end of SPRINT

  1. Weekly or bi-weekly DEMO of completed work
    • Work must be accepted or rejected by the client
    • If rejected, enter as adjusted new work in the ICEBOX.
  2. Do a RETROSPECTIVE or review of what went right and wrong in the past week or two.
    • Consider making adjustments to your process based on your review.
  3. Add, sort and prune items in the master task list — that is, review and revise your EPICS and STORIES. This is where new work enters.
  4. You’re now at the start of a new SPRINT.

Suggested every 12 weeks

  1. Review the process in a deeper way, business objectives and accomplishments, master task list
  2. Decide if you need to pivot or make major changes to your plans.

Suggested Tools

Trello

  • Weekly Sprint board

    • Columns
      • todo
      • doing
      • blocked
      • done

  • Planning Board

    • Columns
      • Icebox — master task list where all possible new tasks start
      • Epics — list of standing big features or products the org plans to deliver
      • Stories — one column per story — each column represents less than 1-2 weeks work - A story column can be moved to the sprint board at the start of a sprint acting as a todo list

Slack

  • One channel for the #project team for communication about the project itself. Bugs, scheduling, clarification should all go through here.
  • One channel for #retrospective
  • One channel for #deliverables

Freeconferencecall.com

  • Daily check-in is face to face at the same scheduled time every day.
  • If can’t face to face, by phone with shared board works.
  • Limit is 5 minutes. If going over 5 minutes, you’re doing it wrong. Say, “Okay let’s schedule for a meeting to discuss this.”
  • Stick to the Do daily rules. See above.

Typical add-ons

  • Planning poker — for estimation
  • t-shirt sizing — for estimation
  • burn-down chart — for velocity tracking and estimation

Opinionated add-ons

  • Allocation for bugs — dev team is some times the same group needed to squash bugs. Making an allocation for bugs as a story within the sprint to account for paying down tech debt.
  • Discovered — oftentimes, actual work will exceed estimate or extremely time-critical work needs to be started mid-sprint. Instead of breaking the sprint, place work in a column called “discovered” (or make the “blocked” column into “blocked/discovered”) and see if velocity during the sprint permits team time enough to do work within the same sprint. If not, discovered task goes back into the master task list/icebox and is handled normally.
  • Separate bug collection tool. Icebox and planning board can be cluttered with too many bug type tasks. Consider a separate board or tracking system for bugs and review along with other task lists.
  • There’s lots of debate about the function of “sprint zero.” My opinion is it’s fair to do a Sprint 0 that is focused on environment setup and process training/agreement and understanding. The debate, which I feel is a pedantic one, is that Sprint 0 should REALLY be dedicated to building a micro-feature to get the team up and running (practically a hackathon). I would still say that for most new teams and efforts, the environment setup and process training is equally important, so this suggests a Sprint -1 and followed by a Sprint 0.