Skip to main content

Poker planning

Last post 04:38 pm November 30, 2023 by abshire gabrielle
3 replies
05:53 am March 28, 2023

Hello,

We are currently reviewing the way we calculate story points on user stories because we feel we don’t have a good proportionality in the time spent between a 1 and 2 story points US for example. Hence we estimate the time spent on several US so that we map this time to SP. The development team want to estimate each US by dividing the front, back and QA estimation. I have a feeling that there is more value that each team member makes an estimation as a whole. Do you have tips for a best practice?

Thanks in advance !


03:14 pm March 28, 2023

If you are going to the trouble of estimating time, why do you need to use Story Points?  Just use the time estimates.  Story points are meant to be relative estimates.  You estimate stories relative to other stories.  Story A is smaller than Story B but larger than Story C.  The fibonacci sequence is used because it not linear but shows a gradually increasing progression.  Trying to decide the difference between a 3 or a 4 is more difficult than between a 3 and 5.  

Story Points are not required by Scrum, just as User Stories are not.  All that is required is a Product Backlog Item that is fully understood by the Scrum Team and that the Developers feel can be done in a single Sprint. Product Backlog Items reach the "can be done in a single sprint" state by the practice of refinement.  This is from the Scrum Guide's section that describes the Product Backlog.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Notice that the "such as" statement.  It doesn't say "must have" or even "should have". It indicates that those are details that could be provided.  The following sentence provides even more emphasis that the attributes will vary based upon need.

Your team appears to want time estimates so use time estimates.  Adding the additional mapping of hours to story points justs adds complexity and obfuscates information. 


06:06 pm March 28, 2023

We are currently reviewing the way we calculate story points on user stories because we feel we don’t have a good proportionality in the time spent between a 1 and 2 story points US for example.

Is this suspected at the time? If so, why don't the Developers just take the matter into account in Sprint Planning, and adjust accordingly?

The purpose of estimation is for Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control. So as long as they can say "that's about the right amount of work for us", that's fine.

Hence we estimate the time spent on several US so that we map this time to SP. The development team want to estimate each US by dividing the front, back and QA estimation

Might this detract from the shared responsibility of Developers to figure out how much work they can collectively accommodate each Sprint? I think you're right to have certain suspicions.


08:17 am November 30, 2023

We are currently reviewing the way we calculate story points on user stories because we feel we don’t have a good proportionality in the time spent between a 1 and 2 story points US for example. Hence we estimate the time spent on several US so that we map this time to SP. The development team want to estimate each US by dividing the front, back and QA estimation. I have a feeling that there is more value that each team member makes an estimation as a whole. Do you have tips for a best practice?

At that time, was this suspected? Should that be the case, why don't the developers simply consider the issue during Sprint Planning and make the necessary adjustments?

To help developers understand how much work they can do in a sprint, estimating is undertaken. Value delivery and empirical process control are the main components of all else. It is therefore OK if they can state, "That's about the right amount of work for us."


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.