Convincing my team that we need to split tasks by feature, not by work type

Question

I'm in an agile team, with some developers, a designer and a ux guy. Sometimes we split some user stories into tasks when we think they are too big.

When doing this, I've always read that we should split user stories into small features (so we can have a potentially shippable product after each task). However most of my team members insist in splitting tasks into work type (e.g. a task for wireframes for this user story, then another for design, and another for implementation). I understand that is a bad way, since we're not getting potentially shippable products, but I can't seem to make it clear for them that we need to change this. How could I do this?

Answer 1

You're both right. (Or wrong, depending on perspective).

When possible/necessary, split Stories into smaller Stories.

One possible guideline for defining Stories is that they should be 'the smallest possible amount of work that, by itself, provides business value'. Another is the INVEST method. Note the 'Small' requirement.

So feel free to break down Stories into smaller Stories. However...

Once defined, let the Development Team split Stories into Tasks however they like.

It's perfectly fine (and common) for the Dev Team to split Stories into Tasks by work type. Keep in mind that just because a Task is done, does not mean the Story is ready. The work for a Story should not be included in the main branch of the product until all of its Tasks are complete. Just because a Story is half-done does not mean your increment is not shippable - just don't ship that Story!

Answer 2

A user story should be implemented within one sprint (usually 1-3 weeks). The spint itself can be organized in any way, actually the agile manifesto recommends a self-organized structure among the team. If this is the case, your team mates are wright.

If the user story is too big and cannot fit within one sprint then it should be broken into smaller stories that fit. If this is the case, your team mates are wrong. And any other organization will not be within the agile methodology, and this should be your biggest argument against them.

Answer 3

I think @Sarov made some good points in his answer, and the most important part is the distinction between stories and tasks.

Splitting stories should never happen based on what level of the tech stack you're working with, unless you can build a complete feature entirely on the front- or back-end. The article here describes Mike Cohn's SPIDR technique for splitting User Stories. Note that none of these are split by "level of the technology stack." Splitting stories should always be vertical, not horizontal. If you're having a hard time convincing your team of this, a strategy that I've used is reminding developers that by splitting vertically we can always display business value to stakeholders, which usually keeps them off of the engineering team's back!

Splitting tasks can be horizontal, especially if most of your engineers are not full-stack engineers. If you have dedicated front- and back-end teams, there's no problem with having tasks for each story that involve different members of the team on different parts of the stack. Just remember that Scrum encourages cross-functionality, and team members should always desire to learn more about different parts of the stack you use. The more cross-functional your team is, the less you'll have to worry about an issue like this.