Forums

By posting to our forums you are agreeing to the Forum terms of use.
How to estimate and create items with zero domain knowledge?
Last Post 01 Jul 2013 07:43 AM by alicemenezes. 10 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
P.Ross
New Member
New Member
Posts:84
P.Ross

--
21 May 2013 01:23 AM
    Hi all,

    I'm currently working as a Program Manager in a company that is adopting Scrum. When a project starts we usually hire consultants to help us out.

    What I see and hear it's that most team have trouble during the Sprint planning meetings. Estimating items relatively is going ok as in the team does eventually come to a consensus but when it comes to creating tasks, teams tend to have problems. My company creates a very specific product in-house and every project is actually an extra module on top of the existing product. So it's very hard for our developers to create tasks as they don't know the existing product.

    Usually during the Sprint planning meeting I hear a lot of "no idea, no idea how the backend system works or sorry but we can't estimate this".

    How do you guys deal with these kind of problems?
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    21 May 2013 12:10 PM
    A team doesn't need to create tasks during Sprint Planning. What they need to produce is a plan for turning the selected items from the Product Backlog into a potentially releasable increment. Tasks are just a conventional way of doing this. What I'd be looking for in your case is a plan for tackling enough of the items to get the Sprint started. The plan can and should be updated as the Sprint progresses.

    As it stands, you already seem to have items estimated as they have been relatively sized. The granularity might be too big to ensure an even burn-down, but even so I'd consider it as being enough to run with until the team gets some experience.

    Also, don't forget that the Product Owner has a duty to explain the product to the team so that they can make an informed assessment.
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    21 May 2013 02:56 PM

    A team doesn't need to create tasks during Sprint Planning. What they need to produce is a plan for turning the selected items from the Product Backlog into a potentially releasable increment.


    I don't fully understand you on this part. I find the idea that tasks are just a conventional way of doing quite interesting, but I can't map it to a real life situation. Are you talking about "Proof Of Concepts" (spikes) ?
    For what I've understand, the team should always be working on delivering Business Value. A plan on how to meet a PBI doesn't really add (direct) value right?

    Perhaps you can give me a concrete situation. Let's say if your team have a Story like: "As a student, I can find my grades online so that I don’t have to wait until the next day to know whether I passed"
    Now pretend that your team added the estimation and now they are in the second part of a Sprint Planning Meeting. Your team members are like "we have noooo idea which tasks are needed. I don't have enough domain and legacy system knowledge to know what is needed. We gave our estimations purely out of our guy feeling.

    What would you do?


    Also, don't forget that the Product Owner has a duty to explain the product to the team so that they can make an informed assessment.


    Our PO does explain his vision and per item, functionally, very clear. He knows exactly what he wants, but again, functionally.
    randyh
    New Member
    New Member
    Posts:35
    randyh

    --
    21 May 2013 04:00 PM
    From the scrum guide:

    "The Development Team consists of professionals who do the work of delivering a potentially
    releasable Increment of “Done” product at the end of each Sprint. Only members of the
    Development Team create the Increment."

    If your development team does not have the technical skills or knowledge necessary to create a potentially releasable increment of product then you need to tackle that first.

    Tasks are not required. The result of the planning meeting is a plan on how the team is going to create a potentially releasable increment of product.

    For what I've understand, the team should always be working on delivering Business Value. A plan on how to meet a PBI doesn't really add (direct) value right?


    In your example, the "value" is a feature that allows students to get test results soon so they don't have to wait until the next day. A plan on what the team will do to implement that piece of functionality will always need to be done regardless of whether you use scrum or not. Sprint planning simply designates a time-box for the team to be transparent about the plan so that everyone is clear on the goals of the sprint.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    21 May 2013 04:01 PM
    For that story, and given no more information than that there is a legacy system, I would expect a plan like the following:

    1 Trace an existing query flow
    2 Write test to exercise existing query
    3 Identify controllers and interfaces involved
    4 Identify persistence model in use
    5 Identify security model in use
    6 Agree design to support new query
    7 Write test to exercise new query
    8 Code to test

    Those aren't detailed enough to be estimable tasks, but they do represent a plan. It should be enough to get things under way.
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    21 May 2013 04:14 PM
    Hi Ian and Randy,

    Any thanks!

    I will certainly pass it towards the Scrum Masters.

    Cheers,
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    21 May 2013 04:22 PM
    1 follow up question though,

    So to sum up, if a team are facing PBI that are "unknown", the advice would be do a time-boxed spike/POC/Plan to figure out more info regarding a particular Stories right?

    Let's say that the (2 week) Sprint Planning Meeting starts on the Monday and due to the described problem, the team decide to do a timeboxed Spike. How do you plan this within the Sprint? (assuming that other Stories can't be done either)

    I do agree that some sort of Spike/POC/Plan needs to be done during the Sprint, but how do you integrate it with the Sprint?

    Sprint Planning Meeting -> Team commit to create a plan timeboxed to say 2 days -> after that do the Sprint PLanning Meeting again?

    Is that the way to go?




    randyh
    New Member
    New Member
    Posts:35
    randyh

    --
    21 May 2013 04:46 PM
    What are you referring to when you say a "PBI that is unknown"?

    Javier Peris
    New Member
    New Member
    Posts:8
    Javier Peris

    --
    26 May 2013 06:00 PM
    Hi P. Ross,

    in my opinion it must be remembered that SCRUM is a framework for continuous improvement based on the commitment but understand the fault. The first sprints are usually the most difficult and there will be deviations in the estimates and the speed of the team.

    In principle it is normal to start with fewer team members but with some experience in the matter. It is important that the PO choose properly team members to ensure a good ROI.

    If there are no experts in the field I think it's a clear impediment and therefore is the SM who must solve it. The best course of action depends on many factors, but some technical talks by experts or some days of coding might be some suggestions as well as the SM agree with the OP a first sprint as proof of concept.

    Also remember that if a functionality involves other group (backend team) is necessary that team members are present for both groups can commit to carry out the story.

    Regards.
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    09 Jun 2013 01:42 AM
    So the sum up.

    The output of a Sprint Planning Meeting is not about coming up with estimated items but rather a plan to change PBI into shippable increments.

    So how do you integrate a plan within a Sprint?

    Something like this?:
    1: Start Sprint Planning Meeting
    2: PO explain each item functionally
    3: Because its new for the team a timeboxed (e.g. 3 days) "research" is done.
    4: After 3 days the team gather during the official Sprint Planning Meeting (while its halfway the week) and tries to extimate the Items.

    Is this the way to go?

    When we are talking about a plan, are we talking about a plan per Item? (So basically timebox per Item a research item)

    What i am wondering is this creating a plan moment, is this like a timeboxed item within a Spring? Do you estimate is? Is it a one time event or you can do it every Sprint again?
    alicemenezes
    New Member
    New Member
    Posts:39
    alicemenezes

    --
    01 Jul 2013 07:43 AM
    I get that too. How do you deal with answers like "no idea"


    ____________
    http://www.agiledistributed.com/tes...Agile.html
    You are not authorized to post a reply.


    Feedback