Skip to main content

Story Pointing in Scrum and re-estimating a ticket

Last post 03:16 pm November 18, 2019 by Timothy Baffa
3 replies
09:19 pm November 15, 2019

What is a Story point? When should a ticket be re-estimated. 

I had interesting conversation with my colleagues and would highly appreciate what do you think about Story Pointing and re-estimation.

I am a SM, We have always been Story Pointing as this:

Our Team: We have scrum team with team members having specialized skills. So for us, Complexity along with the size of a ticket gives us the effort its takes to complete the ticket. When I say size, I am not talking days/hours at all.  This is Story points for us. 

Other teams: It should never be the size, it should just be the complexity. 

 

Re-estimate:

Our Team:  When a ticket falls through, we re-estimate the ticket. Afterall, the goal for our team is reducing the product backlog. We don't care of the SP are not getting accounted during the Sprint closure.

On another team that I work on, we give credit by breaking the ticket down and assigning SP for completed work, create a new ticket for the remainder of the work. 

Other teams: Even if the ticket fall through, the complexity remains the same. Why should the story points change? They will remain the same in the next sprint. Example(A 5 SP ticket spilled over to next sprint. Team's average velocity is 25 SP. Other teams take 25 SP worth of work in next sprint including that 5 SP spill over ticket. So, they don't re-estimate the ticket even though its 90% complete. Because of these reasons: 

1) The complexity is still the same 

2) Because it adds more pressure to complete the ticket because they had that ticket as the spill over 

What do you guys feel is the right approach? We would like to follow the approach that makes sense to all the knowledgeable people here. Please guide me through the right approach.

 

 

 


10:42 pm November 15, 2019

Our Team: We have scrum team with team members having specialized skills. So for us, Complexity along with the size of a ticket gives us the effort its takes to complete the ticket. When I say size, I am not talking days/hours at all.  This is Story points for us. 

What efforts is your team taking to inspect the effectiveness of your procedures and how do you measure it? Does your way of estimating lead to trustworthy estimations, and in turn to well-informed Sprint Goals and Sprint Backlogs?

On another team that I work on, we give credit by breaking the ticket down and assigning SP for completed work, create a new ticket for the remainder of the work. 

Does cutting up un-done items (and apparently calling parts of an item done before they are actually done - hint ;) ) help refine your abilities to reach sprint goals?

What do you guys feel is the right approach?

Oh, that's easy! :) The right approach is the one that your team evolves, in your environment, and for your product and customer, through continuous adaptation based on empiricism.


09:22 am November 16, 2019

Does the re-estimating activity must always mean that your estimation go down, i.e form 13 to 5? Can't it go up, i.e from 13 to 21, even when taking account all those team effort that was already done?



What is the main point of estimating in the first place? If we do not re-estimate not done PBI at the end of the sprint, do we miss some kind opportunity to inspection? Is it still a transparent situation? Do all of us are truly on the same page with understanding what remains to do?



Just asking.


03:16 pm November 18, 2019

This has been previously discussed in several other threads, with varying opinions around the preferred approach.   The below is my (strong) opinion on this topic:

  • The main thing to always keep in mind regarding story points is that they are planning estimates to help a Scrum Team determine how much to accept in the upcoming sprint.   They are not something to be "credited" to a team
  • Treating story points as a measure of team productivity can be easily gamed, and subsequently renders any metric based on story points (i.e. - velocity) meaningless
  • Any decision to carry over unfinished items to the next sprint without re-estimating the remaining work incurs waste, as teams need to translate original story points into what is truly remaining (i.e. - it says 5 story points, but it really isn't 5 story points anymore...)

 


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.