ryanwold.net - Civic Tech, Bitcoin, and Open Government Innovation

Title

Text

My favorite software teams find collective flow.
Ideally, a shared, big picture understanding is complemented by a shared understanding of the moving pieces involved to evolve software and deliver value to users.

Here, I'll describe how a feature is requested, tracked, prioritized, tested, shipped, and communicated about.

---

Features are requested as GitHub Issues or Trello cards in the Inbox column. (Your code repository and kanban-style backlog tools my vary)

Trello is the working source of truth. So, GitHub Issues get Trello Cards created so everything can be tracked in Trello.

Items in Trello's Inbox column typically move from the Inbox to Icebox, then to the Backlog. Items move to Icebox if the work is valid and deemed valuable. Items move to the Backlog if they are "well-defined". Well-defined being defined as:

* having a user story written - `AS A ___ I WANT TO____ SO I CAN ______`
* having acceptance criteria written - `GIVEN WHEN THEN`

```
AS A <type of user>
I WANT TO <do and or achieve something>
SO THAT I CAN <realize some value>
```

```
GIVEN some set of preconditions.
WHEN this event or action occurs
THEN this behavior is observed and state is asserted
```

### With items processed into Icebox and Backlog, Prioritize

Prioritize items in the backlog, highest priority at top. Priority is typically defined as "deliver value to the user." Each team must discuss what is priority and why.

### When delivering prioritized features, write tests

As software grows, the surface area and interactions need to remain functional, and developers need to be able to update the codebase with some amount of confidence an application is doing what it intends to do (per tests/specs).

### Ideally, ship continuously

If the goal is to deliver value, there is a natural urgency to ship the code that was prioritized, written, and tested, so users can use it and try it out and give feedback on the application.

### Communicate with users

Different apps have different users bases and different teams communicate with users in different ways.
Regarding technical changes, keep Release Notes with both features and fixes - ideally linking each tagged release to its GitHub URL

### Communicate

An entry