Should a user story be shared between developers? [closed]

I commonly see stories that have back-end and front-end development. For example, consider a large dialog with a few tables and some dynamic controls. We’ll make several stories (maybe one for each table and another for the dynamic control system).

The dev team will then split with one person on the back-end and another on the front-end. This makes it easy for the back-end person to just worry about the structure of the SQL layer while the front-end person focuses on stuff like layout. After the initial interface between back- and front-end is agreed, the two developers can focus their attention to get their part done by the end of the sprint.

Then comes the chaos. Who “owns” which story? What does “in progress” mean or “done”? Should we make two separate stories for back-end and front-end? If so, doesn’t that break the idea of user stories based on feature? Our system has a notion of “sub-tasks”, which eases some of these problems. But sub-tasks add an extra complexity. Is there a better way? Is this a “bad” way to use Scrum?

I have been using some form of Agile over the past few years at a couple places. I have no official training yet, so please forgive any wrong terminology or ideology. I’m just trying to learn practical ways to improve our process.

A “story” is so named because it represents a complete, well, story, from a customer’s perspective. Without either the front-end or back-end, there is no use-case path for the customer to execute.

In your case, I think both front-end and back-end should be a single story. Divide it into tasks. The developers own their different tasks. These tasks can be individually tracked through their phases – In Progress, Coding Done, Module Testing Done, etc.

Make sure you include QA-assigned tasks in the same story – without validation a story is useless. The QA will test the end-to-end integrated story that a customer will see. Only then should the overall story be marked as Done. In an ideal Agile environment, a real customer or a customer proxy also tries out the story in a running application, and marks the story Accepted if it meets the agreed-upon requirements.

If you want quicker feedback loops, try breaking the use-case into smaller end-to-end features. For example, instead of a use-case like “A customer can buy stuff using a shopping cart”, divide it into “A customer can add a product to a shopping cart” and so on… Then complete each smaller use-case end to end as described above.

EDIT:
I wanted to back up the points above with some sources. The characteristics of a good user story are represented concisely with an acronym called “INVEST”. It was created by Bill Wake and popularized by the Scrum movement. Note especially the items on stories being Independent and Vertical.

Some more information here and here.

Who “owns” which story?

Whomever grabs the story. They key from an organizational point of view is one person is responsible for the work. Once you get two people, it’s too easy to pass the buck.

Should we make two separate stories for back-end and front-end? If so, doesn’t that break the idea of user stories based on feature?

It depends. I’ve seen both ways work. If the story is large enough to have two developers work full time on it, then maybe it should be split. If the two developers are part of two different teams, then maybe it should be split. If the two developers will work on it during different sprints, then maybe it should be split.

Is this a “bad” way to use Scrum?

The key to remember is that process is there to serve you, not vice versa. User stories are a way for technical folks and non-technical folks to facilitate communication. They spell out what they’d like, everyone negotiates, and then you provide feedback in the story about its progress.

As long as the process is working for you, it can’t be that bad.

Where we have implemented Scrum models, it is perfectly expected that multiple developers may be involved in a single user story. There may be work for data layer, integration, front-end CSS, infrastructure, etc. The team can band together on the various sub-tasks for a story to get it done.

That being said, one person owns the story and is responsible for updating on the progress of it and ensuring everybody’s done their piece and that it is working together. This is the person for us who reports that a story is “done”.

Like others have suggested, my team also divides our user stories into tasks. This is generally easy to do if you’re managing your user stories via software (such as JIRA or Rally). Then it is easy to tell what parts of the story are moving along.

But an alternative for tasks would be to just reassign ownership as each person finishes up their part. So the story gets passed around — maybe developer 1 starts it with the backend work, then passes off to developer 2 to do the UI. Then it’s passed on to your QA tester for verification. This method should work well in environments where you are using actual cards on wall or if your software doesn’t track tasks.

But in any case, I recommend never calling a story “done” until the team agrees that it is done, including testing. That way everybody has a chance to give their input. And if you combine this with ideas about collective code ownership and code reviews then every story is really “owned” by the team anyway. It may be “assigned” to different people along the way, but if somebody is out (sick/vacation/too many meetings?/other) the work can still get done.

My team often accepts user stories as part of our morning stand-up/SCRUM meeting. That way everyone can easily acknowledge or dispute whether it is really “done”. Other times we just let our QA engineer do that — if she’s satisfied that it’s tested and working, and all the tasks are complete, then we call it done.

Where I’m at today we call this larger project an “epic”. An epic is made up of multiple stories and it can span multiple sprints/iterations. A story, for us, is always given to a single developer and should fit within a single sprint. A single story is then subdivided into tasks. Each of the tasks are completed by the same developer on that story. The tasks are meant to give insight into the progress of the story during the sprint/iteration. As each story is completed, by each developer, the epic shows progress.

The point of the epic is to have a larger goal that doesn’t necessarily fit into a single sprint/iteration. Over time all of the stories are completed and the epic is finished. Epics are placed into a release.

Then comes the chaos. Who “owns” which story? What does “in progress”
mean or “done”?

We demo code every two weeks where the stories for that sprint/iteration must be shown to stakeholders and approved. In this context “done” for a story means that I can show you what it does. A developer owns their story and is responsible for showing it (this part is kind of an over simplification, but good enough for this answer; we coordinate our demos through a single person). “Done” means it can be successfully demonstrated. “In progress” means I have tasks outstanding and the story is not complete. An epic is complete when all of the stories for that epic have been successfully demonstrated.

Now this is the perfect case progression. We have stories and demos that fail, users that want something else, etc. Above is the goal and for the most part it works.

Filed under: softwareengineering - @ 04:29

Thẻ: agile, scrum

Should a user story be shared between developers? [closed]

Some more information here and here.

Who “owns” which story?

Whomever grabs the story. They key from an organizational point of view is one person is responsible for the work. Once you get two people, it’s too easy to pass the buck.

Should we make two separate stories for back-end and front-end? If so, doesn’t that break the idea of user stories based on feature?

Is this a “bad” way to use Scrum?

As long as the process is working for you, it can’t be that bad.

Then comes the chaos. Who “owns” which story? What does “in progress”
mean or “done”?

Now this is the perfect case progression. We have stories and demos that fail, users that want something else, etc. Above is the goal and for the most part it works.

Filed under: softwareengineering - @ 04:29

Thẻ: agile, scrum

Thiết kế website giá rẻ

Danh mục

Should a user story be shared between developers? [closed]

Should a user story be shared between developers? [closed]