Skip to main content

Just how far does velocity go in allowing a PO to estimate future work?

Last post 07:35 pm March 29, 2020 by Piotr Górajek
2 replies
04:08 pm March 29, 2020

One of the benefits of having a (specific) dev team (over successive Sprints) estimate story points before sprint start and then summing the story points of completed users stories (velocity) is that the PO can use the that team's velocity to estimate how much work that team is likely to produce in the future.

Correct?

If this is true, then I'm wondering: If the PO is perusing the backlog and wondering how long it will take to implement story "foo", the PO will be able to use the team's velocity to estimate this for "foo" only if "foo" story points have been estimated by the team.

Correct?

If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?), then the PO is able to estimate the future only out that far, and no farther.

Correct?

If so, this doesn't seem like such a great benefit for the PO.

Am I missing something?

 


06:51 pm March 29, 2020

If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?)

If certain Product Backlog items were not estimated -- however roughly -- would the Product Backlog then be well-formed?

The Scrum Guide says:

"Product Backlog items have the attributes of a description, order, estimate, and value. <...> Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail."

 


07:35 pm March 29, 2020

(...) the PO can use the that team's velocity to estimate how much work that team is likely to produce in the future.

Correct?

Yes and no, this is no a golden rule that is always correct, I would say that if you will look only on that, then you can also in most cases just flip a coin and your likelihood will be the same.

If this is true, then I'm wondering: If the PO is perusing the backlog and wondering how long it will take to implement story "foo", the PO will be able to use the team's velocity to estimate this for "foo" only if "foo" story points have been estimated by the team.

Correct?

Well, can you truly map relative estimates into a determined time unit? Could a PBI estimated by the Development Team on 8 Story Points take 2 days to make it "Done" and other PBI estimated as 8SP could take less than 8h?

 

If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?), then the PO is able to estimate the future only out that far, and no farther.

Correct?

Not necessarily, those thinks are only a small part of the overall picture. There are other things that you can measure that may guide you into the future with some sort of confidence.

If so, this doesn't seem like such a great benefit for the PO.

Am I missing something?

It's better than no metrics at all and it is easy to track. But it would be better to track other metrics as well, such as Lead / Cycle Time, Throughput, On-Product Index to name a few. You can also track the average amount of new PBIs that appears while the original one is going up the Product Backlog and is decomposed by the team - that might help you to assess how much hidden PBIs you probably have, and therefore any prediction based on i.e. Throughput will be better here.



Just pick some, try it in your context and Inspect & Adapt on the go. Maybe velocity will be enough for you?


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.