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…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …