How to deal with the no-idea answers

#1 - Designate a fixed amount of time to have team member(s) investigate and report back to the team. aka a Spike
http://www.solutionsiq.com/resources/glossary/?Tag=Spike

#2 - Then at the very least you can have a single task "Implement Story". Scrum doesnt require you to breakup PBI's into tasks. It only says that the team should have an idea on how they will go about delivering the value described in the PBI.
If you have Test/Documentation in your DoD then you can add "test" and "document" tasks also.

#3 - Suggest that instead of saying "I have no idea when it'll be done" that the develop use "For the next workday, I will be doing X,Y, and Z to move this PBI towards done"

You are doing grooming (estimations and PBI breakdowns) during the sprint planning meeting. You should consider moving that work to short grooming sessions performed during the sprint instead. This will allow your devs and PO time to get more information about the business and technical domain related to the story if not enough is known.

In my experience planning meetings go more smoothly when the team isnt doing PBI effort estimates during the planning meeting.

Some possible answers:

1. Estimation problems in SPM part 1
a. Good backlog grooming. See: http://www.scrumcrazy.com/Why+do+Product+Backlog+Grooming%3F#Three%20Ki…
(also be sure to see the related article links around backlog grooming at the bottom) (some people call "backlog grooming "backlog refinement" -- they are the same thing)
b. Encourage the team to retrospect on this obstacle and maybe do a root cause analysis on why this happened. There is possibly something your team could do better next time.

2. Uncertainty around tasks in SPM part 2
a. Good backlog grooming. See 1a above.
b. Or, do a "spike task" or tasks. Essentially, create a task to remove the uncertainty around what the tasks should be. They way I usually coach this, there is the "spike task" which has some sort of estimate , and there there is a "big bucket placeholder follow on task" which also has a rough estimate -- usually larger, but not always. Then, the purpose of the spike task is simply to remove the uncertainty. Once the spike task is complete, the person or people who completed can propose a set of "follow on tasks" to the Dev team, that will replace the placeholder tasks. The "follow on tasks" need not add up to the original estimate for the place holder -- remember... we're Agile and we're allowed to update estimates whenever there is material new information. Make sure that all of the tasks are estimated so that you can track the "remaining work daily"(burndown, etc) as per the Scrum Guide.
c. Encourage the team to retrospect on this obstacle and maybe do a root cause analysis on why this happened. There is possibly something your team could do better next time.

3. Uncertainty in Daily Scrum
a. Encourage the team member to ask for help or get a "second pair of eyes" looking at the challenge.
b. If the gray area is technical, these kinds of things happen, but they should be rare. If a second or third pair of eyes doesn't cure it, then just have them estimate the amount of work remaining (which may be a guess at this point) and keep truckin. The Dev Team should probably decided on how much more time they want to spend on the issue before pursuing an alternative path.
c. If the gray area is because the team doesn't understand the acceptance criteria, then consider doing User Stories. See: http://www.scrumcrazy.com/User+Story+Basics+-+What+is+a+User+Story%3F
d. Encourage the team to retrospect on this obstacle and maybe do a root cause analysis on why this happened. There is possibly something your team could do better next time.

Thanks for the question, P. I added my answer to 2b above to my "Sprint Tasking Tips" article(now tip#32). Thought you might be interested in that article too:
http://www.scrumcrazy.com/Sprint+Tasking+Tips

Best of luck, and hope we helped!

Hi Charles,

I have a follow up question regarding point 1: estimation problems during SPM1
First of all the root cause is that the department has been working in silo's for any years and eventually all the developers left without any transferknowledge. The software has grown in the last 5 years and many (external) developers have been working on it without applying any best practises. (documentation, coding standards, testing etc)

So now we have a brand new (also external) team working on a project. The developers are skilled professionals, but what i have heard, its hard for them to come up with an estimation. There is just no domain and legacy knowledge available...

Can you explain to me how a grooming session would help? Im affraid that it would be a not effective grooming session because the domain & legacy knowledge just isnt there.

Should i be looking at Spikes instead? If yes, how do you implement a Spike?
Is it 1 Spike for all or for each PBI the team creates a Spike to tackle the uncertainties.

In the situation you describe backlog grooming sessions become even more important. They give a team a heads-up on the work that is left to be done, in terms of its business value, priority, dependencies, and overall complexity. I can see that a new team would benefit from multiple such sessions.

The key thing is to get the stories relatively sized. This skill is a function of three things - business knowledge, general development experience, and an understanding of the technical domain. *Any one* of those is enough to produce an estimate. You've already got developers with good general experience, and may well have good product ownership or other business representation. That's two. I'd say the team is good to go and I'd coach them accordingly.

Can you explain to me how a grooming session would help? Im affraid that it would be a not effective grooming session because the domain & legacy knowledge just isnt there.

One of the outcomes of a grooming session could be that the Dev Team has figured out that they have a lack of knowledge or basic understanding around a future PBI's technical implementation. It is perfectly acceptable for the Dev Team to then add tasks to the Sprint Backlog for the *current* sprint to do investigation. The theory here is that time can be spent to remove the uncertainty and lack of knowldedge *before* the story is taken into a sprint.

See Tip#8 here:
http://www.scrumcrazy.com/Tips+for+Effective+Backlog+Grooming

I disagree with your statement unless you bring it into a real context.

Re: your statement,

"b. If the gray area is technical, these kinds of things happen, but they should be rare."

I disagree to some extent. Technical gray areas will abound, until *all* silos are broken down. And even then there are other drivers; company wants new tools, new languages are required, people come and go, etc.

I work in the mobile computing industry and stuff changes, all the time. It is a very dynamica environment. It literally breeds "technical gray areas".