Forums

By posting to our forums you are agreeing to the Forum terms of use.
How to deal with the no-idea answers
Last Post 06 Aug 2013 11:20 AM by Demir Ateser. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
P.Ross
New Member
New Member
Posts:84
P.Ross

--
12 Jul 2013 03:30 PM
    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...


    randyh
    New Member
    New Member
    Posts:35
    randyh

    --
    12 Jul 2013 04:40 PM
    #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/resource...?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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    12 Jul 2013 04:51 PM
    Some possible answers:

    1. Estimation problems in SPM part 1
    a. Good backlog grooming. See: http://www.scrumcrazy.com/Why+do+Pr...20Grooming
    (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+Stor...r+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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    12 Jul 2013 04:57 PM
    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!
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    12 Jul 2013 07:04 PM
    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.

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:571
    Ian Mitchell

    --
    15 Jul 2013 04:45 AM
    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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    17 Jul 2013 05:52 PM

    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+...g+Grooming
    Demir Ateser
    New Member
    New Member
    Posts:2
    Demir Ateser

    --
    06 Aug 2013 11:20 AM
    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".

    You are not authorized to post a reply.


    Feedback