Tracking User Stories with Trello

The idea of a user story is simple: rather than writing extensive documentation about the features we’d like to build, why not just write them as stories instead? And not just any stories but stories of real users using the product. Not with a lot of technical details but just in plain language that a user might use. Hence the name user stories.

When people create tasks they tend to write down the feature they’d like to see implemented. But this alone is too ambiguous for developers to come up with a solution. There needs to be a little more flesh to it. Who would use that feature and why? 

Here’s a template for a user story:

As a [type of user]
I want to [do something]
so that I can [get some benefit]

The idea of this structure is that when a person picks up a story, she immediately gets a mental picture of someone actually using the software and getting some value out of it.  

There’s not much detail in it yet. The story doesn’t tell how to actually implement it. That’s where the conversations come into play. When team members discuss a story, they come up with ideas for implementation, which often results in artefacts such as UI mockups, and architecture diagrams that shape the solution further. This is where an electronic tool comes handy - it can be used as a place to collect all those artefacts and the related discussions for a later use.

Tracking user stories with Trello

Trello is often the tool of choice when moving from simple post-it notes to an electronic tool. After all, its UI resembles a card wall where you can easily move cards around from one list to another. A user story can be represented as a Trello card. You can write the whole story in the card title like this:

But this can look a bit crowded when you have many cards like these in a list. It's not optimal when trying to quickly scan a list of tasks. An alternative approach is to use a short form containing only the what in the card title: 

The who and why can be written inside the Trello card:  

When the team discusses the story, they are likely to end up with more details like checklists of things to do, UI mockups, and discussions. Those can all be attached to a Trello card:

If you want to provide a work estimate for the story, you can do so using the free Card Size Power-Up.

Now that you have a user story fleshed out, you need to make a decision of what to do with it.

Hopefully at this stage you’ve involved all the stakeholders to provide their input, and you’ve got a better understanding of what it takes to implement the feature and what kind of results you can expect to get. If it seems to be a high priority thing, move it to the product backlog, or to the next sprint. You may also come into conclusion that it’s not something you’re ready to build right now. That’s perfectly fine, move it to the “icebox” to wait for a better time.

Remember, there’s always more things to build than there are time and resources available, so don’t be afraid to trash the opportunities that didn’t look that promising after you’ve learned more about them.

Should I use card wall or an electronic tool?

A card wall with physical post-it notes is a great tool for planning your work. Moving cards around the wall and making notes on them with a pen has inexplicable appeal that an electronic tool can't quite match. They come with some limitations though. If you're team is scattered to multiple locations, not everyone can easily access those cards. There's also limited amount of space to make notes, or discuss details. 

But why not take the best of both worlds? Use physical cards for high level planning and ideation. Once you want to start fleshing the task in a more detail, move it to an electronic tool. You can make a habit of writing the id of the Trello card into the post-it so that you can easily connect the two. If you look at the URL of a Trello card, you'll see the card id:

Just write down that id into your post-it note. Whenever you need to pull the associated Trello card, simply enter the card id to the search box:

That card you are looking for is usually the first one in the search results. Handy!

Summary

User stories, like any stories, are most effective when they are shared with others. If you get together with your team to discuss what problems you’re about to solve and to whom, you’ll be more likely to arrive at a good solution.

A good story is one that has enough information to spark conversations. Make sure that the tasks are small enough that they can be completed within a day or two. A typical mistake is to leave tasks too large, which makes it harder to prioritise them, and to complete them within an iteration.