Sprint Planning - Part 2 (How) Task breakdown with estimated hours. How do we emphasis team for estimating task appropriately, not padding up extra hours ?

Scrum Team members are not accountants. Scrum is about delivering increments of value in the form of working product. It is not about delivering story points or hours, and a Development Teaam should not be held accountable in any way for the delivery of points or hours.

Estimates are only made to facilitate discussions about how much work can be taken on and how much work is likely to remain in a Sprint or Product Backlog.

So, if a team knows that development capacity is likely to be reduced by a certain percentage during a Sprint, proportionally less estimated work can be taken on in Sprint Planning. That's as complicated as the arithmetic needs to get.

A good Development Team will look at the size and shape of their Sprint Backlog in the round, and will use summed sizes merely as a guide. If any estimates turn out to have been substantially incorrect, the sizing method can be inspected and adapted in the Sprint Retrospective.

Suggesting the team to attend the Professional Scrum Developer course doesn't sound to be a bad option. We have several public Professional Scrum Developer courses running around Asia this year.

Collaborative environment is a key to the Scrum success. Product owner, Scrum Master and Development Team should work together and there should be a mutual respect. Of course it takes time if you and or your team are new to Scrum.
Here are my thoughts -

"Developers tend to give higher estimates while creating tasks for user stories. We know developers updates the hours such that all estimated time consumed even if it takes less time and they spend time on the tasks other than task relevant to User Stories"

1. You are making generalized statement about the developers, which is not true in most scenarios. Also you have perception about the developer task estimation that they always quote more hours. The perception should change. If we want others to change, the change should come from us first.
2. Even though the Scrum Master can’t tell who should work on what and how it should be done, (Since Development Team is self-organized and cross functional) but he can guide the team if the task is irrelevant to the user story. Scrum Master can point out if the task is not targeted towards the acceptance criteria (AC) defined for the user story. All the tasks should be relevant to the AC. If the developer is working on a task completely irrelevant to the Sprint Goal or AC of a user story, then it is Scrum Master’s responsibility to re-iterate the same and make sure the team focuses on the AC and Sprint Goal.
3. If you feel that the development team is not committing enough (like story/task estimations are always high, you should try discuss this point during Sprint Retrospective meeting on how to improve team’s Velocity. Teach the team on Sprint estimation, Story sizing and relative size estimation, etc., May be development team has environment challenges so the estimates go high. Consider Xtreme programming techniques like Continuous integration, TDD, pair programming etc., Have your lead developer or Architect be a mentor to the developers and help them perform better.
4. If the development team is spending 10% of their time towards product backlog grooming, they should have better understanding over the story/task estimation during sprint planning.

Inspect & Adapt 

Scrum ON..

Scrum developer training may definitely helps the team in other aspects, but not in this context , that is conflict among team to estimate.
I suppose its very clear and not unresolvable issue. Team can see the and think about the rational over the argument, it's easy to percept why this takes this much time. If team members are not coming to an agreeable estimation even with valid reasons, then there is other problem in the team, Figure out that issue and resolve.

If scrum master motivate the team and understand each team members motivation factor, its easy to get unity, collaboration and collectiveness in the teams decisions. in Sprint planning meeting part-2, there is a chance to get the reasons behind the odd man out estimation. It may not be scrum practice but we can employ any good technique in getting consensus over estimation just like the best development engineering practices .

I am also facing a similar kind of issue with a couple team members and because of that the whole team and hence our incremental delivery is impacted. Couple of ideas I would like to take away from the discussion above is to have more n more team building activities to ensure there is trust among the team members along with the scrum developer training. Thanks

"Changing practices is one thing; changing minds is quite another"

Hi all,

Here are my thoughts about this.

1. We will know how many story points the team can complete in a sprint based on the team's velocity in the previous sprint (if this is the first sprint, we can refer to the company's standard). We can even drill down to an average number, such as the number of hours required to complete a story point, which we'll refer to as P (productivity). On the other hand, we will know how many hours we have in total for each particular sprint based on the team size, vacation, and holidays in the sprint, which we will call C (Capacity). Therefore, we can calculate the number of story points the team can carry out by C/P = S. This will not be right all the time, but at least we have a quick and proper way to come up with a reasonable number of story points for the next sprint. We can decide which stories will be included in the scope of the next sprint based on this number S and the priority of stories in the backlog.

2. The importance of task breakdown is to make sure each story will have a relevant detailed tasklist, no more, no less, no overlapping. This is considered the plan or detailed design of tasks for each story. If we spend time doing this and do it seriously, this tasklist will imply an approach to how to complete the story and we will see the team progress very clearly later. We can ask the team to have an exact number of hours needed for each detailed task, but we don't need to change their estimate. We use this to see if the team needs to breakdown further more. Ideally, each task should be completed in less than a day by one person. If a task takes more than a day to complete, we can ask the team to drill it down further. Remember that the hour estimate this time is not used to adjust the number of story points that are already planned for the sprint. Therefore, we don't need to jump into any argument with the team about the exact number of hours. If the total number of hours estimated from the detailed tasklist exceeds the team capacity, you can consider it a risk to complete the sprint scope for this sprint and manage it in various ways, such as improving productivity, adding more resources, or communicating it early to the product owner and stakeholders...