What exactly are the requirements and tasks in Scrum? [closed]

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.