The article about Replacing The User Story With The Job Story by Alan Klement opened my mind about how to write good User Job Stories. Even though, I’m posting about a project I tackled some months ago featuring: User Stories.

Replacing The User Story With The Job Story — Jobs To Be Done — Medium https://t.co/AGymEQ0p2Z

— Miss Kitty Fantastico (@FischaelaMeer) November 6, 2015

At Axel Springer, I’ve used a tool written by myself to fetch issues from a GitHub repository and made it possible to order the issues in categories – or so called ‘Epics’. The labels helped a lot and I had them sorted in more or less no time.

Additionally, I’ve implemented a tool to prepare some manual tests. Lists you could print and check every point you succeeded with. You could click your way through the tool and would be able to setup your own User Story. From a drop-down, you could select if you wanted to be an Administrator, an Autor or a regular User (when speaking of a WordPress system). It then asked you for a thing you wanted to achieve and the advantage you would get from doing so and how you could achieve this (the Definition of Done).

I’ve been thinking about this tool just now, when I read the article. If you followed this blog for some time, I compared myself with Walter from the series Fringe… I’ve done so many things and I simply forgot about them…

Right now, I’m thinking of revamping this tool and make one, which could be used for the backlog and customer support.

Currently, I am using a privately hosted GitLab for my projects, but – taking openness (one of Buffer’s primary values) into consideration – if you want to show what you are currently – right now – working on, you could mirror the information about the tickets to the outside without having users to sign up at the GitLab and potentially allow them to see some code. Also, you might have some conversation with your developers ongoing, but you don’t want the end-user to see this.

Also, you may want to streamline the bug reports which are sent to you, so you have the user (connected with their profile – being it your platform or any other social network) and you can check the problem from their point of view (speaking of rights on your product).

Getting this into place may even further simplify the process of getting things done in a nice way. I’m not 100% sure if this is what someone wants – possibly being observed by hundreds of users – but it may allow you to quickly make some decisions on what should be implemented next. You could open a poll and select let’s say three stories to let the users choose from. The one which wins will be done next. That’s not yet possible, but we’re thinking about it right now, don’t we?

Thanks to @thepaultucker from the Buffer Slack Community, this post was finished earlier than it was planned to, but I saw a certain urge to complete it: His cry for help and the following discussion can be found in the Buffer Slack logs over here.