Skip to main content

Telling Stories Is Hard. Telling User Stories Is Terrible, OR IS IT?

I'm sharing this article as I feel this is one area of the lifecycle my project team don't nail 100% of the time. I'm not saying we don't deliver quality I'm just stating that we could do better... Couldn't we all?

I disagree with one statement in this article though "Only developers are never to be in charge of user story creation". I don't feel there is any reason why anyone on a project team can't manage a story providing it's not done in isolation, you need collaboration to succeed.

It is quite easy to operate with a good user story both in development as well as software testing and quality assurance processes. Though mostly used in Agile environments user stories may be of great value to many software projects. I feel there is no need of defining true value of user stories so I will simply skip that part. Straight to the story creation we go.

  • Where do I begin? Oh, right, with users. A good user story does what? It is describing possible actions a customer/user may take within your product. This means you will be required to step in your user’s shoes and to see things from his perspective (which is challenging by default as you are aware of your product’s insides). This will go easier if you will focus on step by step scenarios describing one particular action as a login process. Etc.
  • Another helping trick is using so called ‘personas’. The goal of this method is in allowing you with a wider view of your stories. Simply create a plausible user and ask what your solution should do to provide this user’s goals with required success. There are even many templates for different personas available for downloads so this step may prove to be easier than expected.
  • One man may not work on one story. Good user stories require collaboration. Only developers are never to be in charge of user story creation. Things are best done when both the product owner as well as other involved teams are working on user stories together.
  • Stories are to be precise and simple. Great user stories usually are using active voice and contain zero confusion. Leave all the information that does not qualify as essential behind a story. Basically a great user story consists of a persona stating what it wants exactly and why does it want things that way. Other information is unnecessary and is adding complications that are presenting minimal value when resolved. Although this step may be considered personal to any team as projects do tend to differ. Yet it is great in 95% cases.
  • Minimalistic stories are actually unachievable without starting with something large and epic. Create big and meaningful user stories consisting of multiple steps and break them in smaller portions. And remember to add criteria allowing user stories to succeed or to fail. Meaning conditions that are to be met for the story to become your personas success.
  • Try using visualisation like paper cards or any other tools to keep user stories visible all the time.
  • User stories are not panacea and your team will never be possible to recreate all your users might be doing within your product. This method is still great, but don’t expect it to cover 100% of all customers will be doing to your software.


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Leeds Testing Atelier - April 2018

The Importance of Building a Good Community of Practice

Within every organisation i think we can all agree that 'collaboration' is a major factor to the success of any project or initiative.

As organisations grow, new teams are created and existing teams fragment from each other, this is natural and i doubt that will change.

So what impact does that have to an organisation?
Stress in the work place? Unmet expectations? Relationship breakdown? Low Morale? Dissatisfied Clients? Collateral damage is inevitable.
When clients are dissatisfied, they often take their business elsewhere, which costs your company money. Poor communication can lead to high employee turnover, which creates a cost of hiring and training for new positions. At the least, with lower productivity and an unclear sense of purpose, poor communication causes employers to pay for work hours that are not efficiently spent, costing money, affecting efficiency, and keeping employees from reaching their true potential.
Its sometimes difficult to work on projects where you/y…