Skip to main content

How to deal with the no-idea answers

Last post 12:20 pm August 6, 2013 by Demir Ateser
7 replies
Anonymous
04:30 pm July 12, 2013

Hi,

I notice the following problems in Scrum teams and i'm wondering how a Scrum Master can assist in these situations:

During estimation at Sprint Planning Meeting part 1:
- Yes we know what the customer functionally wants and the PBI is clear, but we have no idea how complex this item is because we have no knowledge what needs to be done (code) to meet the functional requirements...

During estimation at Sprint Planning Meeting part 2:
- We have no idea what kind of sub-tasks are required to meet this PBI. We can name up a couple tasks but in general no idea...

During stand up: (a developer has been working on a task for several days)
- I'm currently working on task x of PBI y but i have no idea when its finished because its a grey area for me (also for the rest of the team members) im currently doing trail and error...



05:40 pm July 12, 2013

#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.


05:51 pm July 12, 2013

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.


05:57 pm July 12, 2013

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!


Anonymous
08:04 pm July 12, 2013

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.


05:45 am July 15, 2013

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.


06:52 pm July 17, 2013


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


12:20 pm August 6, 2013

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".


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.