I recently blogged about why the Agile tenet of people and interactions over processes and tools was so important. Please feel free to give it a read – hope you don’t find it too pious. That got me thinking – what’s the minimum set of tools I would need to run a functional Scrum team? Sometimes we get remarks from those passing our Scrum-board along the lines of: “Isn’t it funny, all this modern technology and we’re back to post-it notes and blu-tack.”
I roll my eyes, but actually it is kind of funny! I took some pictures around the office to try and figure out what our favourite tools were. I’m not including actual development tech here like PCs and compilers, debuggers, etc. It should be noted we use TFS for backlog (and defect, for our sins) management and it’s hard to imagine not doing so. I’m going to be bullish and assume we could happily kick it to the curb though.
We don’t use post-its for User Stories because they’re too small. We prefer cutting up yellow A4 card into quarters and using a Sharpie. Interesting side-note, I’ve recently been able to make the link between heavy Sharpie use with sudden attacks of dizziness.
What you see above is my very simple filing system. I put Stories to revisit released functionality in one pile (R-1), Stories for the upcoming release in the middle pile (R+0) and all future or delayed Stories in a third pile (R+n). This seems to work fine.
The white paper blu-tacked to the cards are the latest versions of the Acceptance Criteria. Once pinned to the board, these will be moved to one side so both things can be seen at once. The Acceptance Criteria change over time and with collaboration, so I often have to print and slice new versions. I’m not currently happy about the environmental impact of this.
This is how we stick the Story cards to the board:
The smiley stickers are something we use in Sprint Planning that a former Scrum Master invented. They are cute, but potentially could be dispensed with.
Planning Poker is awesome and we use this set from Mountain Goat. We’ve tried other cards which vary from less good to ridiculous.
If you’re serious about involving the team in estimation you need some of these.
Here’s our Scrum board, with a typical burndown on the left. Note this one has been generated by TFS which is quite useful to be honest.
The desk bell is a relatively recent addition. Once someone gets a Story to Done-done, they ring the bell to tumultuous applause from the whole office. Whenever I have to explain it, I say: “Every time you hear the bell ring, it means the Product just got slightly more awesome!”
Most people love the bell, but some (grinches) hate it because it’s too jolly or something.
The Red Button is even more recent and what brought in by a developer in a moment of inspiration. It’s from some game-show board game. The use of this is not subject to strict guidelines, but normally it’s pressed when a Story fails validation, or a nasty defect is found, or quite often when someone (me included) is having a particularly trying day.
I tried to use this “pomadoro” timer for keeping time in meetings, but everyone hated it because it’s so jarring when it goes off, so we never use it.