Skip to main content

Doesn't high level estimation feels a bit weird?

Last post 04:02 am March 5, 2014 by Ian Mitchell
12 replies
Anonymous
01:44 am February 28, 2014

Perhaps it's just me but I always have a weird feeling when estimating high level PBI's. Yes, I understand that it is an guestimate but everything the team estimate will be taken into their velocity at the end of the sprint.
So when wrong estimations are done, the team velocity can be wrong (because perhaps a story was estimated a 5 while it was a 13) and/or you take something that is small (a 3) into the sprint which isn't a 3 at all.



05:35 am February 28, 2014

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.


Anonymous
06:03 am February 28, 2014

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?


07:07 am February 28, 2014

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


Anonymous
10:15 am February 28, 2014


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



10:52 am March 1, 2014

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


11:52 am March 1, 2014

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


Anonymous
02:48 pm March 1, 2014


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"


Anonymous
03:02 pm March 1, 2014


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


03:04 pm March 2, 2014

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.


03:47 am March 3, 2014

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


03:12 am March 5, 2014

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.


04:02 am March 5, 2014

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


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.