How to estimate and create items with zero domain knowledge?

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.

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.

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.

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.

Hi Ian and Randy,

Any thanks!

I will certainly pass it towards the Scrum Masters.

Cheers,

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?

What are you referring to when you say a "PBI that is unknown"?

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.

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?

I get that too. How do you deal with answers like "no idea"


____________
http://www.agiledistributed.com/testingDistributedAgile.html