Team focusing on tasks, but not on User Stories

Question

We have an architecturally layered application, with web frontend, java backend, java and python microservices, DB etc. so when we do a User Story representing business value, it's mostly broken down into 2-5 different technical tasks, worked by multiple people (we have tech specialization rather than cross functionality unfortunately). The problem is that it seems everyone is focused on delivering their tasks only, and at the end of the sprint we oftentimes run into problems of lack of integration between layers and User Story doesnt get delivered end to end or a lots of bugs appear right becore the sprint review.

Has anyone had this kind of problem, and how to address lack of full story ownership ?

Answer 1

I have good news for you: you do have a cross-functional team! The Scrum Guide defines a cross functional team as this:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

Don't get me wrong, overlapping skillsets will definitely be helpful for the team to develop, but you have what you need to get started. Teams like yours deliver on business value all the time.

One of the challenges you might be facing is that people seem to be measuring their success based on completing their tasks. Does the team share their completed user stories at review? Are they asked to explain why they were able to complete half of a number of backlog items but couldn't finish one?

One technique I've seen PO's use is to add only one item to the sprint. When the item is done, they add another. The PO assumes responsibility for inefficient use of dev time and lower velocity. This stresses that they are valuing delivered value over busy-ness.

WIP limits are another structural way of reenforcing the same thing. So are sprint goals.

It sounds like what the team leads is really just alignment on what success looks like.

Answer 2

When you have a user story, someone grabs it, and either says "I can just implement that user story and deliver it in a reasonable time frame", or that person says "that user story is an uncomfortably large chunk of work, so I need task A, B, and C done, and then I can implement the user story".

Whoever grabs the user story is responsible for implementing it. So that person should create subtasks. And those subtasks should be described with enough precision so that with all subtasks implemented as specced, the user story can be implemented. (Story points should be divided up. If three subtasks are needed then the original user story should have quite a few story points obviously).

If you implement the subtasks and then fail to implement the user story, then either the subtasks did not provide what's needed for the user story, or they were not specced well enough. It may be that you design the subtasks by committee, with people interested in the tasks themselves and not in the user story; you will get better result if there is someone who has a very strong motivation to get the subtasks right and that person designs the subtasks, and that will be the person responsible for the whole user story.

And importantly, the subtasks count as "delivered" not as usual when QA accepts them, but when the person responsible for the user story accepts them.