This post documents the agile flow I used with a particular team.

  • As PM on that team, I wanted to eliminate any time spent discussing "how to move forward."
  • If we had that time, I wanted to spend it thinking about "value." I'd rather spend energy searching for the right hole to dig than debating the best digging technique.
  • So I set up the operational process upfront and made "how we work" into a complete routine — agile, in other words.
  • This post is a lightly edited version of the document I created for that team.

What is this document?

  • The principles and operational flow for running agile
  • The tools we're using (Zenhub) and how to use them
  • A Q&A covering implementation questions

Why introduce agile?

  • To build a team that focuses on users' stories = solving their problems
  • To increase productivity and eliminate wasted deliberation time
  • To establish a rhythm
  • To build in a habit of reflection

What is NOT the goal?

  • Writing a lot of code
  • "Doing agile"
  • Using Zenhub
  • Centralizing information in Github

Setup

Tool being introduced: Zenhub — a Github extension. We want to manage all information in Github. Install the browser extension for your browser.

Operating assumptions

  • This is designed for the same place, same team, same period, with close communication. Install this directly into the team.
  • As a reminder, the goal is not to introduce agile. Don't lose sight of the purpose.

Operating principles

  • Goal: improve creativity and productivity
  • Start small, get used to it, evolve toward the optimal style

Basic terms and rules

  • Sprint: the development period. Also called an iteration. One cycle runs from Wednesday to the Wednesday two weeks later.
  • KPT: a retrospective of the sprint run on the Tuesday before it ends. ("KPT" stands for Keep, Problem, Try — a common Japanese retrospective format.)
  • Epic: a user problem we want to solve (e.g., "Change the top page UI to something more trustworthy")
  • Issue: a task required to achieve an epic. Break these down as finely as possible. Aim for scope achievable by the implementer in one day or less.
  • Estimate: also called story points — a relative estimate of implementation cost. Use a baseline task as "1" and estimate other tasks relative to it.
  • Icebox: an idea list of things we want to do. Anyone can file items freely. Items move to Backlog.
  • Backlog: the implementation list for the product. The PO maintains the order = priority at all times. Development generally proceeds from the top of the Backlog.
  • Daily scrum: a.k.a. the morning standup. Done every day.

Operational flow

image

agile flow

Sprint days 1–13 Available for implementation through release: basically 9 working days.

Implementation Implement Epics in the Sprint Backlog in priority order.

QA QA at the issue or epic level. QA is basically done within the team.

Release Release at the issue or epic level. Avoid Fridays. Policy is to release as fast as possible and smoke out bugs.

Measurement Design the measurement method for each Epic in advance.

Sprint day 14 Reserve one day with no implementation or similar work.

Spec definition Bring the spec for the next Sprint's Epic (+ a bit more) to a finalized state. Break Epics into Issues together with software engineers.

Estimation Assign estimates to Issues. Ideally use relative estimates, but since perfect estimates are impossible, use rough hours-to-release as the estimate for now.

KPT Goal: "surface KPT items about how the sprint went, and decide on actions to take in the next sprint."

Milestone determination Determine milestones from the top of the Backlog based on estimates, importance, and deadline (PO).

Team lunch Hold a team lunch on the last day of the sprint. Use it for light retrospection and team building.

Things done continuously outside the sprint

  • (Anyone) Create Epics or Issues in Icebox for problems you want to solve or ideas you have, and add appropriate labels.
  • (PO) Review Icebox contents and either close them, move them to Backlog, or leave them in Icebox.
  • (PO) Determine Backlog priority.
  • (Team) Output spec details to Issues or Epics (discuss with the team as needed).

Q&A

Q: What happens at Daily Scrum?

A: A quick verbal check-in where everyone speaks and shares: KPI review, burndown chart review, announcements, sprint issue progress, epic status updates.

Q: How do we manage story points for design?

Design work doesn't touch source code, and UI design incurs time during the spec-definition stage. The intent of this question is: do we track that? Manage it quantitatively the same as regular Issues by assigning Estimates. This makes retrospectives easier. Concretely: merge the previously separate design repo into the main repo.

Q: What counts as an estimate of 1?

A: Use a baseline Issue as 1. For now, use the estimated hours to release as a rough estimate. Estimates set in estimation sessions are generally not changed.

Q: What do we start with on day 14?

A: Spec definition → estimation (including Issue breakdown) → Milestone determination. Lock the schedule first. KPT can be inserted at any point.

Q: How do we manage PRs?

A: Manage all work in the working server repository.

Q: What about "do it when there's time" Issues like refactoring?

A: Anything developer-driven goes directly into Backlog as an Issue, with the assignee manually adding an estimate. As before, "do it whenever the time is right" — manage Issues on the kanban board.

Q: How do we determine Issue priority?

A: Follow the Epic priority = the order of the list.

Q: What if the estimate doesn't match the actual time?

A: Please comment on the Issue: "Actually took X." Don't change the original Estimate — the goal is to improve estimation accuracy over time.

Q: What if an Epic that was created becomes unnecessary?

A: Comment on why it's no longer needed, remove the milestone, and close it.