Who writes the technical ‘user stories’ in scrum

scrum

I know that a product owner should write a user story in scrum.

A user story is describing a feature for the end user.

But who describes what needs to be technically developed and how it needs to be implemented

and where is that information stored concerning scrum?

That would really interest me!

I see a big lack of knowledge in our company when developer start to implement the story but they do not know HOW to implement it!

For example they have to deal with a legacy COM API and have no idea how to handle it or they are not that technically skilled with WPF/WEB or whatever.

How does scrum help that people to start with the user story?

Best Answer

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:

As a non-technical user, I need to have a simpler interface with the API

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:

Document and understand the current API
Design new API
Implement new API
Whatever...

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".

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit.

I give you a couple of examples:

keyworded articles, which allow advertisers to have more effective adverts
CAPTCHAs, which are there to stop moderators having to deal with spam manually.

Most technical stories actually provide a business benefit, but it's rarely for the users. Phrasing them in a different way can help. I normally use Chris Matts' Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

This explicitly recognises all kinds of stakeholders, including the development team. Now you can phrase your technical stories too, calling out the business benefit:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

I've written a couple of blog posts on this: They're not User Stories, and Feature Injection and handling technical stories. Hope they help.

Scrum Project – Who Handles UX?

The interaction designer

UX != UI You need a experienced interaction designer to deliver good user experience, contrary to popular belief that is not a programmer. For all of you programmers who think they can do UX (that includes me) let me say this. Getting good at interaction design requires at least as much time as getting good at programming. How much time have you spent doing pure interaction design?

In the initial phase it's the interaction designers responsibility to:

Extracting the actual goals of the solution from the product owner
Define the personas that will be using the solution.
Write scenarios that are stories on how the solution will be used.
Compile a design document that leaves little room for ambiguity from an UX standpoint

During the project it's the interaction designers task to make sure that those guidelines are followed and address any additional issues that will arise (and they will).

Many programmers will take afront to this approach I'm sure since everyone feel that they're the exception that can design "wonderful" interfaces, you're probably not. On the other hand a good interaction designer - programmer relation is often very nice for the programmer as well as they don't have to fight against a "stupid specification". Unfortunately good interaction designers are hard to find in my experience but they are out there.

As always I deeply recommend Alan Coopers books on the subject ("About Face" and "The Inmates are running the asylum")

Best Answer

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

Scrum Project – Who Handles UX?

Related Topic