Example Of Technical User Story

[Zada Odome]

ATechnical User Story is one focused on non-functional support of a system. For example, implementing back-end tables to support a new function, or extending an existing service layer. Sometimes they are focused on classic non-functional stories, for example: security, performance, or scalability related.

Another type of technical story focuses more towards technical debt and refactoring. And still another might focus on performing technical analysis, design, prototyping and architectural work. All of these are focused towards underlying support for base functional behavior.

The basic User Story is structured towards functional descriptions of system behaviors. Most often the user drives them, i.e. they align with a usage scenario that a customer would follow in leveraging the application or system. On the other hand, technical stories are often driven to support this upper level behavior. I often call them infrastructural stories.

Technical User Stories are often forgotten during backlog maintenance or grooming activity. The Product Owner and the team more easily gravitate toward the functionality and defer the technical infrastructure to later. This happens for new applications (defining base architecture and design) and ongoing maintenance efforts (extending architecture and refactoring) alike.

One of the best ways to expose technical stories is to perform a Story Brainstorming Workshop as defined by Mike Cohn. I would also include end-to-end Release Planning as another effective tactic. When you take an end-to-end or holistic view to the work to deliver the entire project, then the technical stories often emerge with the discussions.

Give a solid hint about decomposing them out of the base story and perhaps creating another Technical User Story that would be focused towards a sub-service related to handing 2-phase questions. I could easily see doing this, particularly if the estimates on the base story are relatively large.

While functional strategy is important, meaning how will we integrate and demonstrate customer facing stories and features. I find that technical strategy is even more important. Consider this the architectural and design workflow for the development effort. Technical strategy should address functional and non-functional support, end-to-end demonstrability, technical risk, and testing concerns.

Non-agile-hater here. Fleshing out the details of implementation and determining the tasks that need to be done happens during the sprint planning meeting, which will turn the user stories into actual tasks/requirements for the sprint. The failure of many agile processes is that the sprint planning meeting is actually supposed be done largely by the developers...if it is just the product owners, they'll just decide to get the moon. This is where you'd come up with a (rather nebulous) user story like:

While the product owner defines which user stories are the highest priority, then the programmers take those priorities and turn them into a list of tasks (called the sprint backlog). This is where you get the idea of how you are going to implement things...the sprint backlog can be as technical as you please. This is also where you'll find out "to achieve a simpler API, we'll have to refactor that crazy COM API. Anyone know how to use that?". When the answer is "Hell No" you'll start to see that the scope of that user story might be larger than it seems. Given that, you should could break the user story into the tasks:

Given this, it is OK to negotiate the user stories to break them into smaller changes. The agile methodology means that you want to approach what the person wants in incremental steps. So you may say "Hey look. We can't overhaul the API in just one iteration. Lets split it into 'As a non-technical customer, I need a well documented API' ect".

The Dev Team writes the technical things. Scrum helps you a bit but not much with the technical breakdown resp. getting started on a User Story. Scrum is almost What-World-only. The technical breakdown is How-World.

There is a What-World and a How-World. As you felt correctly, User Story is for Users, generating Business Value aka Secondary Value in the What-World. Scrum is mostly What-World only. It says little to nothing about the How-World, basically no more than "How-World is the responsibility of the Dev-Team".

Usually, Backlog Items which are for the How-World are not called User Story but Technical Task or Subtask. Many tools allow breaking down the User Story from the What-World into Subtasks in the How-World.

I found it helpful to do a break-down of User Stories into Subtasks during the Backlog Refinement meetings or at least the second part of the Sprint Planning Meeting (for some teams Sprint Planning 2 Meeting).

With inexperienced teams I found it helpful to strive for Atomic User Stories during the Backlog Refinement and Sprint Planning. An Atomic User Story is a User Story which cannot be broken down further into Smaller User Stories without loosing its Business Value entirely. In general User Stories don't need to be Atomic, I just found that it helps me with inexperienced teams.

If I have Atomic User Stories and they seem to need further breakdown apart from the Acceptance Criteria to be implemented, it means to me that something is not working at the optimum level. Either the architecture is wrong / too complicated, i.e. technical instead of business-oriented. Or the team is inexperienced. Or both. In any case, action would be required to improve the situation by training and spreading knowledge.

Today, the Scrum Master is mostly understood as a Managerial Role, and that's bullshit. Originally, the Scrum Master was, and I advocate this, a Technical Role, not a managerial role, just like the Coach in XP.

Ideally, the Scrum Master rotates among those experienced developers who also have sufficient managerial and communication skills until everybody in the team is living "Inspect and Adapt" so deeply by heart that the Scrum Master becomes redundant; nobody and everybody would be Scrum Master at the same time.

But beware, Scrum Mastery is more like cooking, not like cleaning the table and washing dishes. You might want to rotate who cleans the table and washes the dishes, as everybody could do that. But you wouldn't want to rotate the cooking onto everyone, because there are people who can't cook or don't like cooking, and you want to eat good food.

Scrum also just talks of the Dev Team. Roles like Architect or Lead Engineer do not exist in Scrum. That doesn't mean that they're forbidden, it only means that Scrum doesn't say anything about them. Scrum proclaims a Self-Organizing Team, which means if the team declares an Architect, the team has an Architect. That's not defined by Scrum, but it's compliant with Scrum. I'm not proclaiming dedicated Architects (I worked as a designated Architect for years, and although I liked it, I'm fundamentally against the idea of a designated Architect), just giving an example.

The short answer is this: the product owner is responsible for creating the stories that the team must deliver. It is the team that decides how to deliver the stories. If part of the delivery involves some technical stories, it is the team that writes those stories. The team then works with the product owner to decide priority.

This is not an Agile problem. Problem is that team does not have enough technical knowledge to complete a user story (agile) or a requirement (traditional). Can Agile help in this situation?No, if the team was not selected carefully and no one in the team has enough technical experience to perform their tasks.Yes, If some of the team members has good technical knowledge who can help other team members to perform their tasks. For that team needs to be self-organizing, and should know it's strength and weaknesses.

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:

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.

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.

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'

3a8082e126