Who writes the technical ‘user stories’ in 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?

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

Short Answer

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.

The breakdown provided by Scrum is:

User Story -> Acceptance Criteria

The breakdown people often use on top of this is:

Epic -> User Stories
User Story -> Subtasks
Acceptance Criteria -> Acceptance Tests

Plus, the team might write Technical Tasks for things they know need to be done (i.e. install IntelliJ IDEA for everyone at the start of the project) but which have no Business Value.

For further guidance on how to breakdown work, look out for XP (Extreme Programming), Clean Code, Pragmatic Programming, Software Engineering, CRC-Cards, OOP / OOA / OOD, Design Patterns, Refactoring, Working Effectively with Legacy Code, TDD (Test-Driven Development), BDD (Behavior-Driven Development), ATDD (Acceptance-Test Driven Development).

Long Answer

How Scrum Thinks

What-World and 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”.

User Story vs Task

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.

How Scrum Helps and Where that Help Ends

The help of Scrum for the How-World ends at a few points in the Sprint Planning Meeting:

[Sprint Planing Meeting] The team discovers misunderstanding of the story if different team mates come up with different Story Point estimates during the Planning Poker -> Discussion.
[Definition of Ready] The team does not accept User Stories which are too big (Story Points too high). A rule of thumb found in many Definition of Ready is that the Story Points must be less than half the team’s velocity.
[Definition of Ready] The team does not accept User Stories without sufficient description of Acceptance Criteria. Acceptance Criteria are sufficient if the team has enough confidence on how to start writing the Acceptance Tests.

A few tips on the Level of Scrum

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.

And don’t do “(Architecture|Design|Implementation|Test) of Feature X” as User Stories. I recommend that you even try to avoid this as a Subtask.

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.

Beyond Scrum

The Scrum Master beyond Scrum

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.

It is all too easy to rely on Scrum and the Scrum Master and thus fall into a huge gap because Scrum says almost nothing about the How-World.

Rotating Scrum Master

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.

The good thing about rotating the Scrum Master between expert developers is that the team is more likely to learn about more methods.

The Self-Organizing Team

From Scrum’s perspective, the team must find out itself, ideally with the help of the Scrum Master.

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.

Acceptance Tests

User Stories have Acceptance Criteria. These Acceptance Criteria are turned into Acceptance Tests

Other stuff

For a list of more stuff for breakdown, see How to break up a programming project into tasks for other developers?

Hope this helps.

Whoever is best qualified on the team needs to break down the requirements from product owners into actionable user stories. In my experience, we’ve used the following approach:

It has always been a developer that writes the stories based on discussions with product owners.
These stories are then estimated (based on points or time) by developers
The product owners then decide on how things are prioritized.

If the developers don’t know how to implement a story, then one of theses cases might be true:

The task might not be clear enough (add more
details/screenshots/mockups)
It needs to be broken down further so
that the specific tasks are clearer
It needs more time so the
developer can research, and learn how to implement it. (When estimating this task, add more time to account for this)
The developer
is not qualified enough to implement it and it might need to be
assigned to someone else, or the developer needs to be helped by
someone else.

You can take this course on SCRUM at Udemy for free and learn about individual aspects of the SCRUM process – https://www.udemy.com/scrum-methodology/

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.

Again, the PO decides what to build, the team gets to decide how to implement those stories.

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.

please remember the following Agile priciple.

“The best architectures, requirements, and designs emerge from self-organizing teams”

This happen because in Agile environment team trust is high and they delegate work among themselves.

Filed under: softwareengineering - @ 21:15

Thẻ: scrum

Thiết kế website giá rẻ

Danh mục