I changed the format of my team’s story cards on our Kanban board recently. I think the previous format had been in effect for around two years.
Since formally picking up Scrum, a few years back, which involved transitioning from an electronic story tracker to a physical one, the format had been to write out the long for of the “User Story” template on the card:
People other than myself wanted this to be mandatory at the time, regardless of the type of work involved, with the bizarre and vague rationale of “consistency” being used as the justification.
Around two years ago, acting on some great advice, I flipped the format thusly:
The thinking here is that it’s really important that features are implemented for the right reason, first and foremost. The reason is made mandatory and brought to the front. The user is made mandatory to avoid the ubiquitous “As a user” waste of space.
This format was an improvement, in the same way, I guess, that a technical instruction manual written only in French is an improvement over one written only in Estonian (for someone like me who only speaks one fluent language, but can have a crack at one or two main ones).
The problems are:
There’s a massive temptation to back-translate the reason from the feature: So that we can log users, we want a user logging system. Reading the card out loud becomes one of the most excruciatingly tedious exercises ever attempted in meetings. It’s possible to turn even a whole iteration of totally awesome stories into a grey and bleak stew of bland-ware simply by reading aloud the titles of the stories. Good luck figuring out what each card is about without grabbing your reading specs and doing an extreme close-up, like you’re trying to read the small-print on your bank’s latest T&C changes. Good luck finding the card on which you’re working on the board without peering at each card like you’re a doctor inspecting a strange but very small rash. The new format goes back to basics, whilst still retaining the emphasis on “why”:
The title matches as succinctly as possible the team’s vision for what the change means. It shouldn’t be too prescriptive, and should still be stated in terms of outcomes rather than presumed solution. The title takes up the top half of the card. It can be read at a distance of 10 feet without causing irreparable eye-strain. It also allows room for post-its to be pinned to the bottom half of the card if necessary.
The bottom half of the card starts with a question: “Why?“, followed by the reason for the story. Usually starts with “So that…” but it’s not a hard and fast rule. This section is done in “grown-up” writing, so you can fit just enough text in here to provide a justification. There’s no need to read this section from a distance, but it provides valuable context when reviewing each story close-up.
There is also a number top left for tying into the electronic system (which mirrors the physical for offshore teams) and top right for estimation.
The net effect is more positive in every way than the previous format: the board can now be read and understood with a single glance; and the total amount of Why-ness which can fit on each story card is increased.
Everyone loves the new format. Apparently, they’d been silently moaning about it for a long time, but never felt it worth bringing up in, e.g. retrospectives, etc.
The moral of the story: no-one should be able to make a rule which affects you if they don’t need to live with the consequences. Your board, your rules.