Technical user stories or development related tasks

Question

I have some task in my Jira backlog that I don't know if them should be inside a user story. There are tasks related with development, server, configuration, etc. User didn't ask to have those task/features but as a developer we know that we need to have them. e.g:

Minify code with gulp task

I could convert that task into a user story as:

• As a user I want minimize website size so navigation is faster

I could change role for developer but that will not be a user story:

• As a developer I want a automatic system that minify the code so website size is smaller

Is this task a good example of creating user stories where there is not user story? A user story with (too) general tasks. e.g:

• Configuration

Or should I just have it as a simple task (no user story) in my backlog:

• Minify code with gulp task

Other examples of technical user stories:

• Change app name and icon
• Proxy api requests with nginx
• Buy domain
• Configure SSL

Answer 1

Creating user stories is to get the conversation going and to give the team context to understand the problem at hand to create the correct solution. Also it forces the writer to think about the value it adds. Using something like INVEST makes sense here.

If the value of the technical tasks is clear I think using a user story format is just waste of time. Question yourself why you want to write it in such a format, what do you gain? Just for writing all tasks in the same format is a invalid reason if you ask me.

In your example users do not want to minimize the website, that is the solution. They want it to be faster, but do they really or is it a developer thinking the users wants this? Writing a user story about "Users wanting a faster website" could lead to more solutions that just minimizing it.

Question value, find a way to do it, do not limit yourself to the user story format. Find out what works for you for each different type of task. I would be fine with simple and clear tasks on my backlog as long as we can INVEST it.

In the end it is just about getting the work done! :)

Answer 2

I have some task in my Jira backlog

Where did they come from? Typically the Product Owner will be managing the product backlog and adding in user stories to signify what they want.

User didn't ask to have those task/features but as a developer we know that we need to have them

Then speak with the Product Owner and explain to them the value of the work. I'm sure the Product Owner will see the point of the work and will create a story that signifies the value to the users.

If, however, you are talking about routine development tasks (like setting up environments, adding configuration, etc.) then just add them as separate tasks (don't bother with the user story format). It is the development team's responsibility to deliver a quality product. They don't need to justify each and every task they do to achieve that.

Alternatively you can wrap them underneath an existing user story. For example, say the first story you plan to do in a sprint is to set up the welcome page for the site. Wrap up all the technical tasks you need under this story (such as getting the SSL certificate, configuring the proxy, etc.). That way, when you deliver the first story you also deliver a releasable increment.

This will make the story bigger, but that is fine as it simply reflects the work you need to do to get the first story out the door.

It is not unusual for Scrum teams to only deliver one story in their first sprint. This is for the reason stated above, they wrapped all the foundation work into that first story.

Answer 3

With any project stories are written within a context of assumptions. "the website will be hosted", "users will have internet access" etc

Sometimes these are clarified with a "Definition of Done" or a set of "technical requirements" which apply to any story. But I would suggest you attack them as a "Sprint 0"

In Sprint 0 you setup the environment and frameworks you will be using, choose languages and frameworks, buying domain names etc. This would include Continuous Integration and Deployment scripts, so compressing and bundling scripts etc would be built into the build process. In your particular case 'create a build script which runs gulp on all files'

The idea is to get all the setup tasks out of the way, so that you can concentrate on delivering features for the project rather than constantly being hit by technical blockers, "we have to wait for the firewall" or "CI is broken again"

At the end of sprint 0 you should have a basic "hello world" project up and live with unit/integration/acceptance tests or whatever other base requirements you have in place.

From them on its all about adding extra features into this base project, following the template of what is already there. Rather than having to invent or discuss technical solutions.