How to correctly define tasks in a user story? And can you split the tasks between sprints?

Question

I'm fairly new to Scrum and I'm working with a group of colleagues on a project to learn more about it. Long story short our project is simply creating a website for tourists of our country where they can simply create or use courses in a certain city.

What we did is think about user stories (We didn't really do any UX Research so just consider these stories as valid) that are relevant to what we want to make. For example, consider the following story:

As a tourist, I want to create courses according to my requirements.

This is just a example, we have around other 15 stories. And since we are new to this process, we defined tasks of stories that we saw more fitting with the story. For example we need to make a login/signup page but we couldn't make a story for it so we included it in the most relevant story. So there are few stories with extra tasks. And since we followed this approach, we actually estimated the tasks and no the stories (somewhat a hack?). Now the problem we're facing is we need to use a scrum tool to help us visualize our work, we chose TargetProcess which is free. In this tool story points are obviously given to stories, while estimation by hour is given to the tasks, and each task is a part of a story. Now if we need to work on a task, we can't do so unless we move the whole story into the sprint backlog. So if a story has only one task planned into the sprint and the rest are not, that would create a problem in creating our burn down charts. So my question here is what could we do to make this work?

Answer 1

It sounds like your user stories are too chunky and not independent enough.

I would recommend that you work through your backlog and break down your user stories making them much smaller whilst at the same time being completely independent or as close to independent as possible.

It should take between 1-3 days for one user story to be complete. If it's bigger than this, you likely need to break it down.

This is a great resource for breaking user stories down: http://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flowchart.pdf

In my experience time-estimating tasks is not that useful. Focus on creating and estimating small independent stories and the tasks are optional depending on the developer that picks up the story.

The tasks are the technical activities that 1 developer or a pair of developers will do to meet the acceptance criteria of the story. Tasks should never takes days to complete.

Answer 2

Welcome to the community, Amine.

While not explicitly prescribed in the Scrum Guide, how you choose to break down work during refinement is an integral part of building your solution in an iterative, incremental fashion.

There are a number of models to help with this part of the puzzle. One of the more widely used models is the INVEST model of breaking down user stories. The INVEST model states:

A good user story should be:

"I" ndependent (of all others)

"N" egotiable (not a specific contract for features)

"V" aluable (or vertical)

"E" stimable (to a good approximation)

"S" mall (so as to fit within an iteration)

"T" estable (in principle, even if there isn't a test for it yet)

Perhaps this is already a part of your process, but having really clear acceptance criteria for each story is also important. This acceptance criteria should come from your Product Owner and negotiated with the team once they believe the criteria has ballooned beyond a small effort. Ultimately the team manages their work, but having solid acceptance criteria from a product owner is the first step in empowering them to own said work.

Having solid acceptance criteria not only helps with managing the story, but managing the tasks needed to complete the story, which sounds like the problem you're trying to solve. So long as your stories are well INVEST'ed and have good acceptance criteria, your team should be able to find logical seams in stories (thus tasks) to help manage this issue much better.