2

Recently I have been reading the book, Scrum Shortcuts Without Cutting Corners by Ilan Goldstein. Goldstein mentions that when practicing scrum, you will write user stories and you will write task for those user stories that would then be assigned to one individual. The problem is when I got further into the book, Goldstein mentions that writing tasks are done a specific way. He gives the following example:

User Story

"As a new user, I would like to sign up to XYZ website so that I can start using its awesome services"

Task 1: Design end-to-end functional tests.
Task 2: Generate test data.
Task 3: Develop database layer.
Task 4: Develop business logic layer.
Task 5: Develop user interface layer.
Task 6: Develop end-to-end functional automation test.

He goes on saying this is logical and straighforward and it is how I am doing things now but it is more of a waterfall development pattern which we want to avoid because it is less efficient when wanting to be agile.

What he prefers is this:

User Story

"As a new user, I would like to sign up to XYZ website so that I can start using its awesome services"

Task 1: Develop username/password functionality (including test design and automation)
Task 2: Develop email authentication functionality (including test design and automation)
Task 3: Develop landing page functionality (including test design and automation)

He mentions that rather than a waterfall, we have more of a short trickle. This is great but it is throwing me off a bit. In a team for my project, I am going to have different individuals working on the API, front-end and design. So for the tasks above it seems like all three team members are going to be working on one tasks when only one member should be assigned to one task.

I am just super confused about this. Is my team a special case because we are each specializing rather than being a general programmer? Is there a different way tasks should be written so that it relates to just one of my team members? Are we going to have to work with doing the waterfall development rather the encapsulated result of what it can be? I want to be as agile as possible but it seems like I am running into walls. Any direction/help/solutions would be great.

Improve this question
15
  • Your first list of tasks is a laundry list of technical challenges. Your second list is a list of software features. Do you see the difference? How will you know what to do in the technical list if you don't know what the features are going to be?
    – Robert Harvey
    Jun 23, 2016 at 19:51
  • 1
    So you are saying that people in your team can do only one specific thing and are completely unable to do anything else? Even on basic level?
    – Euphoric
    Jun 23, 2016 at 19:56
  • @Euphoric I don't think they are unable but they are on the team to do one job and that is either the API, front-end or UI/UX
    – Nick Rucci
    Jun 23, 2016 at 20:00
  • 1
    Is it possible for multiple people to work on a task? Actually, looking at the second case, I believe the Task can actually be rewritten as user stories with their sub-tasks being same as in first case.
    – Euphoric
    Jun 23, 2016 at 20:19
  • 1
    @nickrucci "the front end developers work the front end and so forth". Although Scrum teams are cross functional, there is no distinction between team members. No specialized roles. Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule
    – RubberDuck
    Jun 23, 2016 at 21:56

1 Answer 1

Reset to default
1

The goal of scrum is to enable the team to be self-directed. There is no universal right way to write stories and tasks. The goal is for the team to work together to accomplish a task.

When you write a story and it becomes part of the sprint, your team needs to work together to make that story happen. The first step is a planning session where you break down the stories into tasks. Every story is different, as is every sprint, there is no one-size-fits-all strategy for coming up with tasks.

Since it is the team that has to do the work, the tasks that you develop must work for your team. That might mean that the strategy you employ comes straight out of a book, or if you're a mature team it means you do it exactly how you want with complete disregard for all of the books. In reality, most teams fall somewhere in the middle. I that case, books provide a good starting point if you don't otherwise know where to start.

No book knows your product, your stories, your team, or your working environment. The goal is to work together to create great software. You're going to have to figure out what works best for you.

If you are just getting started, do it by the book for one sprint. Maybe two. Do your retrospectives, and take them seriously. Figure out what parts of what you tried worked, and what parts didn't work so well. If it turns out you picked the wrong book, you only have to deal with that for one sprint. Learn, lather, rinse, repeat.

At the end of the day, you have a room full of (hopefully!) smart, motivated people. All you have to do is answer the question "How are we going to deliver this story at the end of the sprint?". Forget about all of the rituals and advice and methodologies, and focus your team on two things: delivering the software, and improving how you deliver the software every sprint.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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