What exactly are the requirements and tasks in Scrum?

Question

I am using Scrum with a small team for the first time and I have gone through many presentations and documents explaining this agile method, but I still don't know exactly what a requirement should be and what a task should be!

Say I want to develop a mobile application that tracks my moves in real time, my first thought was organizing my requirements and tasks like this:

Requirement 1: As a user I can see my position in real time on a map.

Tasks that belong to the requirement 1:

• Code the class that creates a map using the Google Map API.
• Code the geolocalisation class.
• Draw a set of icons to represent the user.
• Write the unit tests.
• etc.

Or, should we organize the tasks this way:

• Write the Unit tests.
• Code the Business logic.
• Code the UI.

Now for the requirements should we have:

• As a user I can manage my account.

Or:

• As a user I can login.
• As a user I can logout.
• As a user I can reset my password.
• etc.

Finally is there a level above the requirements in Scrum? I have seen that some people separate the feeatures and the requirements but I can't see the benefit? If features exist in Scrum, what do they represent exactly?

Thank you!

Answer 1

I still don't know exactly what a requirement should be and what a task should be!

Be careful.

When in doubt, please re-read the Agile Manifesto. http://agilemanifesto.org/

The point is not that Scrum has a formal, official, good-for-all-time definition of requirement or task.

Scrum provides you a way to structure your work. The point is to define a deliverable that you (and your team) can create in a reasonable amount of time. A larger and more experienced team may have fairly "coarse" requirements.

A smaller and less experienced team may need to have fairly "fine" requirements.

The tasks are the things you need to do. The order of the tasks isn't part of Scrum. It's part of how you and your team choose to work.

Here's the complex part of Scrum (and Agile): you're empowered to do what needs to be done to build high-quality software on the schedule you defined.

You have to actually think about what you will commit to and how you want to get there.

Or, should we organize the tasks this way:

This is something you must decide with your team. You must build high-quality software in a predictable time-frame. You can do any random tasks you want consistent with delivering software on time. Must folks find that test case first (a/k/a TDD) really helps.

Now for the requirements should we have:

This is something you must decide with your team, your product owner (and perhaps) your users. You have to commit to on-time delivery. If you understand the problem domain, you can write high-level stories and make your commitments. If there is question, uncertainty or doubt, you might want to write lower-level user stories to be sure you make your commitments.

is there a level above the requirements in Scrum?

If it helps you, yes, there can be.

I have seen that some people separate the feeatures and the requirements but I can't see the benefit?

Then don't worry about it. Reread the Agile Manifesto. If features help you and your team and your product owner, then you'll need to define them more clearly. If they don't help the conversation, then you can ignore them.

If features exist in Scrum, what do they represent exactly?

Features are part of a story. They're specific GUI elements or processing steps that help the actor get through the story.

Answer 2

If features exist in Scrum, what do they represent exactly?

The answer depends on where you learnt scrum. I see a feature as an epic user story. It is a goal you want to reach, but it is a too big chunk of work. You can split epic user stories like slicing a cake into [smaller] user stories.

You can read about this practice in Mike Cohn's User Stories Applied: For Agile Software Development book. If you just started doing Scrum, this book will really help you.

An unrelated thing. I noticed that you have separate tasks for unit testing. I don't recommend to do that, because this task will be usually the last thing what the team will implement, and they will find bugs too late. The last tasks are usually implemented quite close to the demo, and you won't have time to fix those bugs.

Consider tasks as very small user stories, which don't have customer value separately, but together they value a lot - exactly as much as their user story, actually. Have a definition of done agreement for tasks, which contains the unit testing as part of the done criteria.

Or you can use XP's TDD.

HTH,

Zsolt

Answer 3

Requirements are from client's perspective of what they expect from the application -- mostly no tech jargon

Requirements are broken down into user stories (tasks -- can be technical).

For example,

As a user I can see my position in real time on a map

This can be called a user story, but may be a little high level since it can still be broken down to smaller user stories. Like,

• As an application, I have Google Map API integrated.
• As an application, I have the functionality to set icons to represent user

etc.

Edit:

But its upto you, user stories can have sub tasks as well, so you can have your original requirement as an user story and can add the things that I mentioned as sub tasks to it. It generally helps to make user stories as small as possible for better estimations on time and resources.