This blog series will focus on how the Wikipedia App Team uses Trello for their day to day, week to week, and sprint to sprint development cycle. In its early days, the Wikipedia App was an experimental project that needed flexibility for its evolution. The team looked at a number of tools like Bugzilla, Mingle, and Trello to wrangle our ever-growing to-do list. We found that most imposed a structure that was stifling rather than empowering, cumbersome rather than fun, and was generally overkill for what we needed.
Trello looked attractive as it took no more than a couple of minutes to see its moving parts, was available on multiple platforms, and was simple to customize. We experimented with it and quickly found that we could make it do most of what we wanted.
For those unfamiliar with Trello, it’s a list of lists at its basic level and it functions incredibly well within an Agile framework. Trello uses the concepts of boards, lists, items, and subitems. Boards contain lists which contain items which in turn contain subitems.
Here is how we use it:
Each idea starts out as a narrative or user story on our backlog board. Most of our stories are written in a “As a …, I want to …, So that …” format. This allows us to have a narrative justification for a unit of work rather than a list of technical requirements. Stories begin their life in the “In analysis” column where the product manager (who acts as the product owner) vets the idea with other stakeholders, involves the Design team, and generally incubates the story. Anyone is welcome to add a story to this column.
When the product owner feels that a story has matured enough, they place it in the “ready for prioritization” column with any required design assets. As these stories increase in number, we begin to see the next sprint forming.
Within a couple of days, the team meets and the product manager discusses the theme of the upcoming sprint. A new sprint board is created and the product manager moves the most important 3−5 stories for a deeper analysis by the whole team. The team meets and collectively refines the story cards to have a clear set of acceptance criteria under the checklist column, flags stories that need additional design, and prioritizes them in top down order.
Within a week’s time, the team meets again, but this time their goal is to estimate and do a final pass on each story card. We use a combination of Scrum for Trello and hat.jit.su to facilitate the estimation process. Once all stories have been estimated, the product manager re-prioritizes, checks against our sprint velocity, and the sprint is ready to start.
Thus at any point we have three active boards:
- Backlog – where all stories start
- Current Sprint – what developers are working on
- Next Sprint – what’s coming up next
Next time we’ll see what happens from the developers’ standpoint during a sprint.
Tomasz Finc, Director of Mobile