This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

"tricky ... as it effects calculations of velocity/points etc" How is that "tricky"? Please explain what you think makes this "tricky". If you have too many stories, you have a velocity problem to begin with, since you mis-estimated. What's "tricky" about that?
–
S.LottSep 12 '11 at 21:17

It really depends on whether you want to prescribe to "Scrum Proper" or if your team is just "agile" in some way, shape, or form......
–
Agile ScoutSep 12 '11 at 23:19

12 Answers
12

In my experiences, stories are either done or not done. There is no concept of an unfinished story. At the end of a sprint, you either completed the design, implementation, testing, integration, and system testing for a story and presented it to the customer for sign-off, at which point it was moved out of the backlog or it remained in the backlog for the next sprint. There was no concept of re-estimation or partially completed stories.

At the beginning of the next iteration, a N point story that was started in the previous iteration and left unfinished was still considered to be a N point story. Our velocity for the previous sprint was used to pull down an appropriate number of story points for the next sprint, starting with the N unfinished points and the top stories until the number of story points in the iteration was the velocity of the previous points.

However, that was just our practice. The key is to be consistent. Whatever you choose, do that at every iteration and don't change - that will affect how you compute velocity and estimate work for future sprints.

I down-voted because I disagreed with the approach since arithmetically it doesn't make sense that those points go nowhere. Then after reading this article I changed my mind since points do not follow the usual rules of arithmetic but they are only a tool to represent business value delivered and of course half-done features deliver the same value as non-existent ones. Unfortunately my down-vote is locked.
–
pgpb.padillaOct 12 '14 at 18:43

The crucial problem is determining how you update size. It's not easy (in fact, nearly impossible, given the ninety-ninety rule), to quantify how many hours (or how many points) are left to develop a software component. The only thing you know is that your estimate was wrong, and when you finish, how much you were off by.
–
Thomas Owens♦Sep 14 '11 at 17:56

The iteration size is supposedly fixed. The best approach (according to me :) ) is to split.
Typically when tasks are not completed within the iteration they are assigned to, I suggest splitting the user stories and move the incomplete tasks to the next iteration. The estimate of the new user story is calculated from the remaining units necessary to complete the original user story. This way you can keep the estimates and also maintain historical references.

Like @hvgotcodes has mentioned, the idea of agile is continuous improvement. So as long as we keep records of stories we split and understand the problems with those user stories, we will have less and less instances of split stories.
–
doc_180Sep 12 '11 at 19:03

Good point; however, IMHO splitting is only appropriate if the split stories still have business value on their own. Just splitting into "done" and "not done" is not helpful.
–
sleskeFeb 2 at 12:31

A. Put the story into the project backlog. If it's still the most important thing, it will be scheduled for the next sprint. If not, the product owner will schedule something more valuable.

B. You get no points for that story for this sprint. When you schedule the next sprint, Only count points for stories completed this sprint. (Yeah, you'll pull in a bonus story at the end of the next sprint. Great. But it's better to get a bonus story than to presume you'll get it done, then you'll have another unfinished story to account for.)

1) create a story to represent the completed work, and a new one for the remaining work, adjusting estimates.

2) analyze why there was a mis-estimate. Stories typically represent commitments, and if a commitment wasn't met, it's kind of bad. Was there not enough analysis up front (i.e. devs didn't know how much work it would actually be), did people get sick, did other bugs prevent the work from being done, etc?

The dilemma: Where do story points for unfinished stories go? The sprint where they are finished? Partial credit in each sprint for the portion finished in each sprint? Here is how I answered the dilemma in a blog post:

Those points go nowhere. No credit. But the team DOES have to complete the work.

We tend to try to brake up stories so that it can easily fit into a sprint, and that it can easily be removed. It takes a certain mindset to brake up the story into deliverable pieces during the sprint planning meeting.

The thing I also found is that if the stories brake up into deliverable pieces (which can be visible or not, or even switched off for a couple of sprints), my team can do all the work on the trunk, and not hassle with doing work on a branch, and then rebase/merge the work later which is always a pain, so that's a bonus.

At the sprint review, the Product Owner, in consultation with the
sprint team and stakeholders makes the decision on done-ness. In
this case, the PO declares that the story will not meet the
customer's needs as intended.

The PO may elect to create a new story and place it into the
Product backlog. The new story, like any story is based on the
information that the PO has about the current state of the product
and the current needs of the customer. This obviously includes the
discussion that took place about the undone story above.

At the next planning meeting, the new story is assessed like any
other. The PO prioritizes and the team estimates effort.

Notes:

The degree of done-ness is a factor in the decision process.
For example, if the team agrees that they are "one hour" from
completion, the PO may agree to delay the done decision. But the
team still needs to demonstrate that the story is done!

On my team, a story is never moved out of the sprint after that sprints review (it's closed as-is). We use the "done-done" rate to use as a talking point during the retrospective. If we moved the story, then it would appear as if our done-done rate was 100% every sprint.

FIRST - Split the stories and assign and divide points to old and new split story - this means estimate the remaining work on the story

For example - An 8 pointer story was 'unfinished' with only 3 point of work completed and team estimates that 5 points is needed for the pending/remaining work - Then update the 'unfinished' story to 3 points and the new split story to 5 points.... makes sense?

SECOND - Split the story and zero out the points from the old story and update the new split sory with the full points of the old story - this is the best practice scrum teams follow.
The credit is given only when the full story is completed and velocity also can be captured properly by averaging out once some iterations are done.