Doesn't high level estimation feels a bit weird?

A team should only admit a PBI into their Sprint Backlog if they are reasonably confident that they can complete it as per the Definition of Done. To have that level of confidence implies a good grasp of the work that will be involved, and that in turn implies the ability to make a reasonably confident estimate.

This confidence can be attained in at least three ways:

- sufficient backlog refinement
- spike investigation of PBI's that are unclear, so as to de-risk any estimate made
- inspecting significant estimation discrepancies during Sprint Retrospectives, and adapting the approach used accordingly

There is of course a fourth item, although it is more of a principle. This is the fact that, in Scrum a Development Team owns its Sprint Backlog and has the right to say "no". If they don't have that right, and are pressured or bullied into taking work on that they are unconfident about, then Scrum is not being followed.

Hi Ian,

Isn’t this a bit in conflict with the idea of providing a high level estimate?
The idea of a using relative estimates and Fibonacci is that the team is able to give an estimate based on user story title and description.

I understand that sufficient backlog refinement is an important step to gain more knowledge of a story, but I’m actually talking about the action before the first sprint. I read a piece by Mike Cohn about that the team should initially estimate 80% of the stories.

I don’t expect the first session to be an extreme heavy weight meeting where we talk about all the stories of the backlog in details in order to get more confidence right?

> Isn’t this a bit in conflict with the idea of providing a high level estimate?

It's reasonable to provide high level estimates for items on the Product Backlog, including those at epic level. However, it would not be reasonable to expect a Development Team to admit PBI's into their Sprint Backlog if they are insufficiently confident about how to progress those items.

> I read a piece by Mike Cohn about that the team should initially estimate 80% of the stories.
> I don’t expect the first session to be an extreme heavy weight meeting where we talk
> about all the stories of the backlog in details in order to get more confidence right?

Strictly speaking, the first sprint should not be allowed to start unless the Product Backlog has been fully sized, and is properly formed with a description, order, estimate, and value for each item. This doesn't imply that the Product Backlog has to be in any way complete, but at any given moment the content of it should satisfy these rules. If you start sprinting with an unsized Product Backlog then you do so at the Product Owner's risk, and that risk should be mitigated as swiftly as possible.

Posted By Ian Mitchell on 28 Feb 2014 07:07 AM
> Isn’t this a bit in conflict with the idea of providing a high level estimate?

It's reasonable to provide high level estimates for items on the Product Backlog, including those at epic level. However, it would not be reasonable to expect a Development Team to admit PBI's into their Sprint Backlog if they are insufficiently confident about how to progress those items.

What do you usually say to your team to convince them that they should give a high level estimation?
This is what i'm struggling with...

Here is what we do when we have to estimate a new feature or EPIC -

Based upon our understanding we break up the work into multiple PBIs and estimate each one of them. The estimation is very high level, may be 100% off the mark. We share it with stakeholders along with risks and assumptions. We calculate the number of sprints required for completing the sprint. Then we start grooming each PBI and ensure that the items for next two sprints are well groomed, another 2 sprints are estimated with Rough Order of Magnitude and next 2 sprints will have just placeholder PBIs. This keeps updating every sprint.

The overall schedule may change based upon the new work identified or change in team etc.. The change is shared with stakeholders during the sprint review and necessary adjustment is done.

Cheers
Sanjay

> What do you usually say to your team to
> convince them that they should give a high
> level estimation? 

I just ask them to do a team sort. If they can't - or won't - at least make a tentative stab at relatively sizing, then that tells me there are other problems. I'll then be having frank conversations with the team about whether they feel competent to do the type of work being requested of them.

Sometimes teams get thrown at a project because they are the only "warm bodies" available. They do not have the right experience and have not been properly trained. Unfortunately that sort of thing does happen, especially when they roll off an earlier project at just the right time. The problem then lies with the employer, as the team are being treated shabbily and product ownership is not being well served.

Posted By Sanjay Saini on 01 Mar 2014 10:52 AM
Here is what we do when we have to estimate a new feature or EPIC -

Based upon our understanding we break up the work into multiple PBIs and estimate each one of them. The estimation is very high level, may be 100% off the mark.

So what do you usually tell your team to give them the confidence to do an estimation?

What I hear a lot for example is the following: "oh there is too much unclear about this story, if I estimate it now it's wrong anyways so giving a high level estimation at this time is totally useless and waste of time"

Posted By Ian Mitchell on 01 Mar 2014 11:52 AM
> What do you usually say to your team to
> convince them that they should give a high
> level estimation? 

I just ask them to do a team sort. If they can't - or won't - at least make a tentative stab at relatively sizing, then that tells me there are other problems. I'll then be having frank conversations with the team about whether they feel competent to do the type of work being requested of them.

So what would your argument be towards to the team to convince them to proceed with providing high level estimations?

Sometimes teams get thrown at a project because they are the only "warm bodies" available. They do not have the right experience and have not been properly trained. Unfortunately that sort of thing does happen, especially when they roll off an earlier project at just the right time. The problem then lies with the employer, as the team are being treated shabbily and product ownership is not being well served.

Or when you only have 1 development team which consists of junior developers and all senior developers already left the building..

One of the great things about Agile estimating is that the relative estimates doesn't need to be accurate. Generally the team will implement a large number of PBI's over the course of a release so the "Law of Large numbers" will apply in this matter.
Some stories are estimated too low, some too high, but in the end it averages out and autocorrect itself. Because we measure velocity the team should detect and correct biases in their estimates. If the team consistently under or over delivers compared to their estimates, the velocity measure will expose it, so it needs to be corrected.

What is important is that the team be "consistent" in their estimates. That estimates are done the same way from sprint to sprint.

There is an article on relative estimation which might help you :
http://scrumorakel.de/blog/index.php?/archives/48-Estimating-relative-s…

From a sprint perspective I think Ian is spot on. All PBIs allowed into a sprint should be small and well understood by the team.
For the backlog I see no point in estimating epics using e.g. fibonacchi . We only decide whether they are epics or not. Items of this size are so uncertain that they need to be broken down further to be estimable with any confidence. If playing planning poker I would throw away all cards over 20 and replace with epic card.

> For the backlog I see no point in estimating epics...

In an agile enterprise where projects are funded incrementally sprint-by-sprint...or at least where a number of sprints are purchased...there would indeed be little point in doing so. When playing planning poker, a team would just throw the question mark card and break the epic down into estimable and plannable stories. It's an impediment they would resolve on-the-spot during their ongoing backlog refinement process.

Unfortunately, most organizations don't fund projects by sprint. They want an up-front costing of a large body of work. To support that dysfunction, an initial Product Backlog has to be drafted and sized, and of course most of the PBI's in that context are going to be epics. Worse, if the intended team don't size the epics, some other pseudo-authority will.

So there is a point to sizing epics...it helps to keeps estimation within the team. Even so, epic estimation should be a rare occurrence in a genuinely agile organization.