Some people in the scrum team think that it's not required to add tasks to a user story

What benefit do you believe that adding tasks to stories will achieve?

It sounds like the development team have some good reasons for not wanting to add tasks. My previous team added tasks to every story as it was helpful for them. My current team don't add tasks.

Both teams achieved the goal of delivering software at the end of the every Sprint.

Adding tasks could be helpful as pointed out but not required.

The team should decide how they want their pbi’s. 

Remember as a Scrum Master you should be servant leader to the team.

Maybe you can start on now all your items but specific items. Discuss the team that it is not required to all but can be useful for items that are estimated to be 3 or 5 days?

It sounds like your Development Team is self-organizing and if Product Backlog Items selected by them are producing Done increments at the end of the Sprint, you should be comfortable with their decision. They are the ones who have to estimate and do the work so it's not a good idea to bog them down with administrative actions.

I tried my best to explain to him but it's not working out.

What have you tried to “explain” to him? Shouldn’t any decision regarding how work is decomposed during Sprint Planning be a team one?

My advice would be to focus on helping the team to have productive discussions about such matters.

What, if any, bad experiences did the team have with not adding tasks to the stories?

Story point will have business value and Task will have technical contents (What actually a member is going to do). SM can insist for task or Sub task only when team is face issue not when a team is achieving or going smoothly)

@Shiva Kumar Gosul, SM can't really insist on anything especially when it comes to how they do the work.  Here is the first bullet point in the Scrum Guide section describing the Development Team: 

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

I have never read anywhere in the Scrum Guide that the Scrum Master can insist or demand anything from anyone in the Scrum Team. 

To the original post, the initial responders gave great insights and answers.  If the team does not see a benefit to creating tasks then there is nothing to be done.  If as Scrum Master you see that there could be benefit, pose it to the team in whole and help them adjust as they see fit.

I have a situation in my scrum team where some teammates are objecting to adding any tasks to a user story and their viewpoint is that since they are responsible enough to finish the story in time than what's the need to have tasks to the story. It's a waste of time and as a developer, I don't like to/want to do it.

Does the team able to coordinate and reach their Goals without adding these tasks ? What are the benefits you think team will get out of adding tasks ?

"Some people think it's not required to add tasks to user story". Well those people are correct. It is absolutely NOT required to add tasks to a User Story. I'll take it even further, User Stories themselves are not required. A Product Backlog Item is all that is mentioned in the Scrum Guide. That can be a User Story with tasks or maybe just a post it note on a wall. 

Dear friends, stop making tools become the process! 

Curtis Slough I like your last point: "stop making tools become the process!"

As others have pointed out, user stories are NOT REQUIRED according to Scrum Guide. They merely serve as a placeholders  for a conversation about the use of product and value to be delivered. User stories are neither contracts nor do they are directions for implementation. If used they should focus on ‘what’ rather than ‘how’. 

I am 50/50 on tasks. If a long running team has shown a track record of success and delivery then why upset that.

If teams have a history of sprints failing for a myriad of reasons tasks can help keep them on track. (not always)

I explain that tasks can be your plan for how the work gets done it's almost like a step 1, step 2,  step 3, complete, story done. 

Some teams use tasks and add components like front end, back end, test. Many places IT leadership demand tasks as a way to quantify business costs. Like it took this many hours and these many tasks so a story costs this much $$$$. 

Don't get the scrum guide twisted. While I adhere to it 95% of the times sometimes you have to adapt and adjust.

"While Scrum guide says  "They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;" 

While this is true that depends on a teams level of maturity. I am not a Micro Scrum Master at all but sometimes you do need to step in create a process even temporarily. Then when a team can do a story to done without tasks make it a reward to not use tasks. 

Think practical! Don't think mechanical and rigid be Scrum but be Agile and Lean.  List the pros list the cons, give reasons have a conversation and decide. 

I agree with most of what is represented here - Scrum Teams should be autonomous, self-organizing, no one tells them how to turn PBIs into product increments, the Scrum Master shouldn't dictate/demand/insist processes to the team, etc.  I also acknowledge that the Scrum Guide does not require the use of User Stories, Tasks, etc.  However, isn't there a balance to be found between a team "self-organizing" and a Scrum Master "insisting"?

For example, if the Development Team decides not to do Retrospectives at the end of each sprint, does the Scrum Master just sit back and say "Oh well, I can't insist they do."?  What if the team decides they don't need to have a common Definition of Done, and just let each team member decide what "done" means as they go?  Does the Scrum Master have to wait for the ensuing chaos to actually occur before stepping in?  I know those are extreme examples, but I think they illustrate a point - I believe the Scrum Master does have the responsibility to insist on certain practices, specifically those that are clearly spelled out in the Scrum Guide.

That brings us to tasks.  While it is true that the Scrum Guide does not specifically mention tasks, it does include the following:

• Sprint Planning answers the following:  What can be delivered in the Sprint, and how the work will be achieved.
• All the work that the team identifies as necessary to meet the Sprint Goal must be visible in the Sprint Backlog.
• The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
• As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated.

While none of those include the word "tasks" I think it's pretty strongly implied; certainly the concept is.  I don't know how else a team can satisfy those concepts without creating tasks; a User Story by itself would not be sufficient.

Finding this balance is something that comes up a lot in our organization, so your thoughts would be appreciated.

@Daniel WiLhite

re: I have never read anywhere in the Scrum Guide that the Scrum Master can insist or demand anything from anyone in the Scrum Team. 

The only reference in the scrum guide that I think moves toward Scrum Master insisting is the following one in the section about the Daily Scrum:

"The Scrum Master ensures that the Development Team has the meeting"

Other then that, as always, you make some well reasoned points that I always enjoy reading. 

Thank-you!

~Jamie N

@James Noble, ensuring is not the same as insisting.  I can ensure that they have the meeting by making sure they appreciate the purpose and benefit of doing so.  I never insist however I do encourage people to try things for the purpose of determining its usefulness. I facilitate the discussions on the effectiveness to help them arrive at a decision.  I'll admit that I have facilitated that they keep trying because there isn't a consensus and "gently guided" them to a conclusion but I have never felt that I did so when it wasn't helpful.  In the end it is up to the team to decide.  I have worked with teams that worked so closely together and were in constant communication that the Daily Scrum really wasn't needed.  But the purpose of that event was occurring in other ways so I took that as ensuring the purpose of the meeting was being fulfilled and ran with it. 

BTW, thank you for the feedback. I appreciate knowing that my crazy ranting isn't always ignored.  

Wow! Very insightful view. I have to admit that I was having a bit of fun when I sent that your way (although my other comment was very spot on).

I am now glad that I did because your answer gave me a slightly different way of looking at it that is more in line with how I feel about servant leadership and that particular requirement.

Reading these forums have provided me with food for thought now on a number of occasions so I am trying to participate a bit more in the hopes that some of my thoughts also help others.

~Jamie N