Sprint Planning - Part 2 (How) Task breakdown with estimated hours. How do we emphasis team for estimating task appropriately, not padding up extra hours ?
We all know Sprint Planning meeting is having two parts - What & How. Inputs to Sprint Planning are Refined User Stories in product backlog, History of Team Velocity, Team Size, Vacations and Holidays. Since Sprint is time boxed, we can calculate net capacity (Net available hours).
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. If we do simple math Sum of Tasks hours <= Available hours, we will be taking less number of user stories in sprint backlog, because bottom of the heart we know if you ask developers to estimate tasks, it will be always more than 200%. If anyone asks question, he can give n number of reasons.
Since development team is self-organized and cross functional, hence we rely on team for better task estimation. Sometimes discussion around task estimation becomes unhealthy. How do we address this as a scrum master ?
1) Should we hold moving user stories to sprint backlog till tasks are re-estimated and do capacity match again ?
2) Should we move user stories based on the team velocity history. (We don’t co-relate user story point with sum of tasks hours created for that user story) ?
3) Should we more user stories than the outcome of math i.e. Sum of Tasks hours <= Available hours ?
4) Have a discussion meeting to understand why each task will take that amount of team, though this is against the principal of scrum ?
5) Should we inform discipline managers ? As per scrum, it is only development team however in reality organization is having discipline model and scrum team is kind of a virtual team.
6) Suggest Certified Scrum Developer training for development team.
What options you will be following in this scenario. Any thoughts ?
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 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 .