Should I assign user stories per team or per team member?

Question

Given: A team of 1 Backend Developer, 2 Front End Developers.

Definition of Done

1. US acceptance criteria have to be met
2. All subtasks in terms of the user story should be completed
3. Back End subtask should be covered with Unit tests
4. US are OK'ed by the Product Owner

User Story

As an Admin I want to be able to View the list of users so that I can know how many users are using the service.

Subtasks:

1. Create API endpoint (Back End)
2. Create the view for the user list (Front End)
3. Create API calls (Front End)

Problem: When we finish the sprint all front-end related sub-tasks are made and only 60-80% of Backend sub-tasks are completed. Because of that our velocity is low, as we complete less User Stories, but in reality, a lot of work was made.

What is the correct way to distribute User Stories/Sub-tasks between devs so that we can see the real velocity?

Answer 1

You are seeing the real velocity. Stories that aren't done don't count. If people keep working on new stories while old stories aren't moved to done yet, that means your team isn't working like a team and some level of process improvement is needed.

Remember that velocity is about delivering value, not code. If it isn't ready to go into production, then it is providing 0 value, so it should not be counted in the velocity.

If your team is unable to attain higher velocity because they are lacking in certain skills, the team needs to try and find a solution for that problem, whether that means training someone else to help them, expanding the team, or changing the division of work within the team so that the person working on the tasks that aren't complete has more time available to complete his tasks.

Artificially inflating the velocity by including things that aren't delivering value is just going to hide the real problem you have: stuff isn't delivering value because parts of the work aren't being completed quickly enough.

As for your title question, the only valid way to distribute stories within Scrum is to give all the stories to the team, and hold the entire team responsible for their completion.

Answer 2

I think what you're calling out is that you have a distribution of skills on the team that 66% of the team can do front-end work and 33% can do backend work. However, the work needs something like a 60/40 skills distribution.

So, what you are seeing is that there is a potential for an increase in velocity if the skills of the team matched the work a little more closely. Especially in this case, because they are so close, cross-training is almost certainly the best way to accomplish this for your team.

Answer 3

First, Scrum is a 'pull system'. In Sprint Planning, a self-organizing Scrum Team pulls items from the Product Backlog into the Sprint Backlog and formulate a Sprint Goal. There is no 'tasks assignment' event/role in Scrum. If you are a Scrum Master then it's time to allow your Scrum Team to self-organize around this. If you are a manager, get the Team's Scrum Master to coach you on appropriate interactions with their Team :)

Second, there may be many reasons why you have failed Sprints:

• Developers work as individuals or silos and not as a Team e.g. front end devs do front end tasks then hand-off to back end developers etc.

• Developers are over-committing to work they cannot complete, perhaps due to external influences.

• Developers feel they need to be busy at all times e.g. towards the end of the Sprint the front end developers are bored so they pull more items into the Sprint, merely hoping others will have time to finish 'their' tasks.
• Developers are being assigned tasks by someone outside the Team :)

I think your first priority is to get to the point where you have completed a number of Sprints where all the work forecast in Sprint gets done. Do all you can to ensure the Devs pull in a vastly reduced number of Product Backlog items. Don't allow new items to be added during the Sprint. I expect the front end developers will complain of having nothing to do: observe their behavior when you tell them to help get the in-progress items finished. Strongly encourage them to either pair with the back end developers in getting items to done or work with the Product Owner on preparing Backlog Items for the next Sprint; strongly discourage them from starting active front end development work on items still in the Product Backlog.

Get the Team accustomed to finishing all forecast work in a Sprint **as a Team ** before allowing them to increment the amount of work they pull in each time. Only increment again after a stable period at the new increased velocity (say, three Sprints).

Answer 4

Try making your stories 'smaller' - let your team define a story that they as a team can work on and finish in a 'day-or-two' Also, keep in mind that the team should "swarm" on stories together, one story at a time!

Answer 5

No, you never ever assign work in Scrum, ever, never!

Help them to self-organise. How does the team think they can solve this problem?

Maybe let them try a work-in-progress limit of 1 for a while. That should shake their world and force them to adapt into helping each other out to complete a user story together.

Answer 6

A task only counts as 'done' when it is deployed or ready for deploy. You don't get half the velocity points for completing the frontend.

The velocity of your team is dictated by the velocity of your backend development. It doesn't matter how fast the frontend developers work if the backend parts of a task are not complete.

In your situation, I would bring in a rule that frontend development on a story can only begin when the backend part is complete. This way, your frontend developers can't race ahead of their backend counterpart.

Doing this will expose how much spare capacity you have in your team. Your job will be to deploy this capacity to speed up your backend development. For example, if your frontend developers are waiting for a backend task to be completed, could they help by writing the unit tests?