Efecte Blog

We all probably had our favorite bedtime stories as a child. One of my favorites was a story about Pablo the penguin. It’s about a penguin who is always feeling cold and tries to come up with different means to keep warm. To spoil the whole story, in the end Pablo surfs with his bathtub through the oceans towards warmth using the ocean water coming from the sink. Physicist buddies of mine would state that it is impossible and against the laws of physics.

Times have changed and now part of my profession is about writing stories. You all probably heard about user stories. And if you have been involved with agile software development, you know that user stories are the building blocks of an agile software development backlog. Stories are sentences in the business language of the end user that captures what the user wants to achieve. In addition to this, user stories should also fulfill the INVEST criteria, i.e. stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Simple right? Well, not necessarily. To create stories that fulfill these criteria, product owners need to grasp the market needs, user needs and iterate over and over again with the development team. This is the bread and butter of product owners in agile projects. The only problem in these criteria is that they have been created to support the agile software development, but agile software development itself does not support creation of easy-to-use software.

So how to create stories that also support easy-to-use software?

1. As a  <Role>, … when writing the stories make sure the user role from which the story is written, has a persona defined
2. Independent: although the stories need to be independent from each other, they also need to map to at least one user workflow to create connection points to existing users’ stories that have been created. Or then, the story itself needs to create a workflow of it’s own.
3. Negotiable: to ensure also the negotiability on the ease-of-use there needs to be sketches the users and product managers can comment and negotiate. Same kind of negotiability needs to be achieved through usability testing of the prototypes and ready-made software.
4. Valuable: stories need to be valuable for the market, and for the buyer, but the most important part in creating easy-to-use software is to make sure the stories are valuable to the real users of the software. The users needs to have a real problem that the software solves – and solves it well thus creating value.

Just as with children’s books the ones that are on the top of the pile are the one read most often – in product backlog the stories with most value are also on the top of the pile. And actually the same applies for the UI design for stories: the stories used the most in the software should be on top of the pile, that is, visible in the first view of the software. Biggest problems in creating the pile arise from the fact that just as most of us had a different favorite story as a child, so do users have different problems that they need to solve.

By creation simple stories that at the same time fulfill all the criteria define above, we are one step closer in creating also simple and easy-to-use software. Impossible could my physicist buddies say. But I assure that we will do this and ride the bathtub side-by-side with Pablo towards the warmth of the south!

Site-note: Actually Pablo is probably riding north, because he is from the south-pole, but I prefer south especially at the moment.