7

My team and I are implementing Scrum in our project. We are at the phase of dividing user stories into tasks to assign to each developer.

I understand the concept of Slicing the Cake where a user story represents a vertical slice that crosses all the technological layers (i.e starting from user interface to middleware to database).

However, when I divide my vertical user story into tasks, it gets divided into horizontal layers. So I end up assigning a horizontal layer task for each developer: one developer would work on the user interface part of the story, another one on the middleware and a third on the database. Thus, in doing so, I feel I am breaking the concept of vertical slicing..

| improve this question | |
  • 2
    Why are you assigning tasks to the team, instead of encouraging them to collaborate on the work? – Todd A. Jacobs♦ Aug 18 '18 at 23:02
  • @ToddA.Jacobs what do you mean? As far as I understood in Scrum, I assign first a group of developers on one user story so that they collaborate together. But then, I divide the story further into tasks, and here I am confused on how developers should work on one story but on different tasks at the same time – nader Aug 19 '18 at 20:06
  • 2
    No. Scrum Teams are self-organizing. You are struggling with the implementation because you’re trying to do work the team should be doing themselves. – Todd A. Jacobs♦ Aug 19 '18 at 22:46
4

Short answer: the tasks are for the team to organize their work however they see best to do it. If that means dividing it up into front-end, middleware, and database, that's fine. This is actually a normal part of the progression for cross-functional teams.

Just because we've put people with all of the skills into the same team doesn't mean they suddenly know those other skills. So they start with a horizontal breakdown like this and probably still isolate certain types of tasks with the individual most skilled at that thing. Usually pretty early in working this way, the team will find itself in a situation where there are too many of X task type for the team member who usually does that to do and someone else will have to step in and help out - usually with some of the easier tasks. Over time, people will gain a broader skillset and will start seeing places where breaking down the tasks into horizontal layers doesn't look like the best way anymore.

The big pitfall to watch out for is if the team ends up in that situation and instead of stepping in to help each other out, the rest of the team moves on to new backlog items and you end up with a pile of backlog items that just has one task type on it. I see this most commonly with testing tasks, but occasionally it also shows up in other types too.

| improve this answer | |
  • 3
    I'd emphasise the part about the team organising their work, it's not any one person's job to slice up stories into tasks. – Erik Aug 19 '18 at 9:03
  • @Erik could you please elaborate on the part "the team organize their work"? Does that mean for example that each developer will chose which task he/she would work on? and should one task be done by only one developer or can a task be shared with multiple developers ? – nader Aug 19 '18 at 20:11
  • 1
    @nader it means that the team will break up the stories into tasks, and then decide how they will complete those tasks. Whether they work on them separately or together is up to them, whichever way they find most effectively helps them complete them. (Technically, it's even up to them if they even want to break them into tasks. The team is in charge of doing the work.) – Erik Aug 19 '18 at 20:39
  • 2
    @Erik Yes, and the team is also 'in charge' of inspecting whether their current 'found way' continues to be the most effective way of ensuring outcomes for users. And the OP (assuming Scrum Master role) is 'in charge' of holding the team to account for doing so. – onedaywhen Aug 20 '18 at 11:16
2

I have found with my teams that the hard part is actually getting the stories split correctly not the tasks, and I find this resource invaluable:

https://agileforall.com/resources/how-to-split-a-user-story/

  1. Prepare the input story: Is it independent, negotiable, valuable, estimable, small, testable
  2. Apply one of the splitting patterns: e.g. interface variations, business rule variations etc
  3. Evaluate the split: are they similar size

Once you have great small and independent stories, breaking these stories into technical tasks is totally optional and some developers like doing it and others don't need to do it.

The point I am trying to make is rather get the stories small and worry less about the technical tasks. You certainly do not need to assign technical tasks to different developers.

Developers should be pulling 'stories' individually or as pairs and then figuring out what needs to be done and if they want to capture things things as tasks go ahead.

| improve this answer | |
1

Vertical Slices are decomposed into Tasks which are specific to each domain and naturally horizontal. You are using this agile concept correctly--BOOM!

The only thing I'd suggest would be consider letting the team choose which tasks they work on. This will help your team become more knowledgeable, more effective, more fulfilled and definitely more agile.

| improve this answer | |
  • You don't have to decompose stories into horizontal tasks - it seems to be a common preference, but not a requirement. – Erik Aug 23 '18 at 5:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.