How Velocity is calculated for User Story Partially done

Why would you want to use undone work to calculate velocity?

Remember to re-estimate the item on the Product Backlog so it reflects the amount of work which is now thought to remain. It can then be planned into a future Sprint. Until then, any partially completed work will be subject to depreciation. 

There appears to be a bit of a gap in the recommendations on this scenario, but I think it is primarily due to difference of focus.  

If you don't count undone work as part of the velocity (which i personally think is a good practice) but you re-estimate if something goes back on the backlog so that the PO/Team can better forecast what they can accomplish in the upcoming sprint you effectively "loose" velocity as the story estimate depreciation isn't captured anywhere.  Tracking against a burn up chart for "milestones or releases" does help somewhat as you see a decrease in the total "work" required which would help increase accuracy of upcoming forecasts.  

However the big question is what your focus is.  This question isn't a big deal if you are focused on value creation vs "velocity" creation.  If work is regularly not done at the end of a sprint that is the first thing to look into.  Undone work creates uncertainty all around, so forecasts are not very transparent no matter how you track things if you are constantly carrying undone work.  If you are measuring effectiveness of a team based on velocity that is also something to ask yourself about (ie what is our goal?).    

Story points are for helping a team forecast how much work they reckon they can take on. The value always lies in the increment.

The moment estimates proxy for value, the gates to all hell are opened. "Story point productivity" is merely the start of the shenanigans and usually just the first knot an organization will tie itself into.

Along with Value the Goal is also to forecast the velocity but if I do not count the Velocity of the undone work and re estimate it in future sprint the Story point will get reduced as it was partially done  in earlier sprint and I will loose those points in my velocity of a sprint.

Thanks!!

It's hard to give a tailored answer, because I'm not sure what your role is, but in summary:

Remember that velocity is an optional measure.

If you're part of the Development Team, it's up to you as a team to track it however you determine is appropriate. Pick an empirical approach, and be open to the entire Scrum Team about how this is calculated. To ensure empiricism, some Development Teams choose to only track items that were Done, and always use the estimate at the start of the Sprint when they were Done. It's imperfect, but has at least a distinct and transparent meaning. The velocity should never force or limit a team to do a certain amount of work. It should only provide a guide, so that the Development Team can offer meaningful forecasts, based on their own judgement.

If you're the Product Owner, work with the Development Team, based on the estimates they give you and their calculation of velocity to provide any forecasts you need to give to stakeholders. Accept that there's no way of being certain exactly how much work will be Done in any future Sprint.

If you're outside of the Scrum Team, tracking velocity may be harmful, as it could incentivize the Development Team to adjust their estimates in some way. I suggest you stop doing this immediately.

If you're the Scrum Master, work with that knowledge to help the Development Team to calculate velocity (if it is useful to them), work with the Product Owner to help her/him manage expectations of stakeholders, and work with the organization to ensure they are not using velocity as a measure of anything of something that it isn't.

Furthermore, if one incomplete Product Backlog Item (PBI) has a significant impact on the velocity, all parties should look at why that is, and consider whether better refinement of PBIs would be helpful in the future.

I fall into the opinion that an unfinished story should be brought into the next sprint with the original point estimate intact and with no partial points awarded to the previous sprint. 



In regards to concerns about velocity planning:

Teams will already need to look at a number of factors when planning a sprint that reduce or increase our expected velocity (things like vacations, client meetings, travel, infrastructure maintenance, or an increase in high priority support tickets). Another consideration is unfinished stories which will likely not be more than 1 or 2 and usually none. When there are unfinished stories a team can factor in how much is already done when building the sprint.



The velocity used for sprint planning is always an average, a little noise in the data doesn't hurt.



I also think this better enforces the importance of completing a sprint. It doesn't matter if you've finished most of a 13 points story at the end of the sprint, what matters is that the team completed their commitment entirely. Velocity swings make for good retrospectives.

Thanks for the clarity!!

Jordon, I'm intrigued by one of the things you mentioned:

I fall into the opinion that an unfinished story should be brought into the next sprint with the original point estimate intact and with no partial points awarded to the previous sprint. 

I'm curious what you would do if new insights or changing priorities now mean it is no longer the most valuable work to be done in the next Sprint.

Does the Product Owner determine whether work should continue on this item? If so, do the Development Team respect that? How does the Product Owner know what the likely remaining work is, so that she/he can make her/his decision?

I fall into the opinion that an unfinished story should be brought into the next sprint with the original point estimate intact and with no partial points awarded to the previous sprint. 

It's not about 'awarding' partial points to previous Sprints, it's about reflecting the true remaining effort left on the Product Backlog.

Velocity is simply a planning metric to be used as a guide by both PO's and Development Teams in determining how much "work" may be forecast for completion in a given sprint.  

How does foregoing re-estimation of remaining work in an unfinished PBI support Sprint Planning purposes?   I would assume that if the full value of an unfinished story is preserved as it is moved to a future sprint, the PO and team would need to somehow flag the story with "asterisks" to help their planning (i.e. - this isn't really an 8-point story, as the team worked on it last sprint).   That is simply a wasteful practice, and adds needless complexity to Sprint Planning.

As Ian stated, when velocity is used in any other manner other than planning, you then embark on a very slippery slope.   Trying to get "credit" for completed work in an unfinished story, or preserving the story point value for an unfinished PBI, both fall into that category.

I know this thread is a bit cold but still wanted to weigh in.

I tend to follow the guidance of those who say "don't re-estimate the story points for a story." Story points, after all, a measure of RELATIVE SIZE, not of effort. The only time to change the story points on a user story, it seems to me, is if you think the original estimate got the story's RELATIVE SIZE very wrong. That means you estimated two stories at 8 points each and you come to decide that story B turns out to be much bigger than thought, so you want to call it a 21, IF it's that far off, it may make sense to re-estimate it. I re-estimated a substantial part of a project once, but it was because the work was estimated by two different esimators, and one estimator's SP were much "smaller" than the others. This was a rare, one-time recalibration.



I definitely would stay away from re-estimating in order to give "partial credit." The issue of how to do accurate sprint planning for the next sprint, if you have items in the backlog that are substantially complete, doesn't seem like a big deal. The team loads itself up with work based on what it thinks it can complete. Backlog work that's part done is only one of a number of factors the team might need to consider as it thinks about its capacity for this next sprint. They almo might need to consider things like Jack being out on vacation two days, or only having the QA person for 18 hours instead of 30, or the fact that one dev is stalled because of an ugly infrastructure issue and may need to shift gears and lose some ramp-up time .... The capacity determination for a sprint doesn't need to be too accurate, nor can it be -- the original SP estimates were rough as well. If you take on too much work, the worst that happens is some stories roll over to the next sprint. If you estimate low, then you'll be pulling stories off the backlog late in the sprint. Neither is a big deal, it seems to me.



Unfinished work rolling over to the next sprint is not a big deal to me, because it doesn't create a problem that worsens with time. Say you have 21 point story roll over, and it's arguably 70% done. If you don't take account of the part that's done, you expect it accounts for its full 21 points, and you underestimate you capacity for the sprint, with the result that you have to ... pull in items from the backlog. Hardly a catastrophe, and the velocity for your last two sprints will even out. Or you go too far the other way, don't count it all, with the result that the 21pt story gets done, but some other story doesn't and has to go back on the backlog. No worse a problem than it was the last sprint.



If for some reason these unfinished stories are piling up, so the amount of "unrealized credit" is growing, that suggests a bigger problem in your pipeline. If you definition of done is not "code complete," but "passed QA," you might see that tickets are piling up in QA. I see this often, and the solution is not to change measures or estimates but to fix your QA bottleneck.



Finally, it's always possible to split stories. For me, the caveat is that you really do need to split a story into two independently workable and testable items. For example you have a work item that says "allow payment by credit card, PayPal or check," and you have everything but PayPal working at the end of the sprint, then go ahead and make a new ticket for just the PayPal. Split the original points for the story in some rough proportion but don't change them. IF the first story is truly done according to your definition of done, mark it complete and add those points to the done column, and throw the Paypal ticket back on the backlog. But definitely don't split off a story that says "remaining work to complete Account Profile screen." The estimated items aren't units of work, they're units of independently verifiable business value.



Sorry, long post. Here are some further thoughts from Mike Cohn. https://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is…;