Splitting the stories and points treatment
Does anyone know if there is anything like when we split stories and move it to the next iteration, the points effort that has been done in the previous iteration for that story will be lost?
For example - if we have a story is for 10 points, and we have done 6 and carrying forwad 4 points of work to next iteration, hence splitting. Will we be loosing those 6 points of work as it was not completed as per the commited in the iteration?
Assuming that the two new user stories both meet INVEST criteria, and will indeed provide value, there's nothing to stop a team from doing what you suggest.
The important thing is that if any points are to be applied to the first sprint, the corresponding value *must* have been delivered in that sprint's increment. Also, any undone work is not being "brought forward" but is instead being returned to the Product Backlog, where it might (but will not necessarily) be planned into the next sprint.
As Ian said, both has to meet INVESTm especially V(aluable).
Don't do something like splitting "As a user I want to search" 10 SP into "As a user I want the search implementation to be startet" 6 SP in Sprint 1 and "as a user I want the search implementation to be finished" 4 SP in Sprint 2
If you can split it like "as a user I want to search for the name" 6SP and "as a user I want to search for 5 other fields" 4SP than it is totaly fine to finish the first story in Sprint 1 and the second in sprint two even if you encounter it late. Important is to really deliver the ones you count.
Philipp is right and gives a credible example of how PBI's can be split. Assuming the value behind the stories is delivered in different sprint increments, the associated points can then be applied to the respective sprints.
They might not be the greatest user stories after splitting. In Philipp's example they are obviously smaller, being 6 and 4 points rather than 10. That helps one of the INVEST criteria. They are perhaps not as independent as they could be, depending upon how the 6 fields interrelate. The important thing is that they are viable as Scrum PBI's, because they allow the associated value to be delivered in an end-of-sprint increment.
There's something we need to be quite careful about though. What are the reasons for splitting the story in the first place? If we care about getting a piece of usable value out to a customer as soon as possible, then that's fine. If we care about how the numbers look and "delivering" story points, then we have a problem. In Scrum you deliver value, not points.
> In Scrum you deliver value, not points.
Just to reinforce this, in a good Scrum implementation no-one would care about "losing" points for work partially completed in a previous Sprint. All that would happen is the affected PBI would be re-estimated, and the total size of the Product Backlog would be reduced accordingly.
In other words, any work partially completed in a sprint can simply have the effect of shrinking the Product Backlog. That's a positive outcome because it indicates that less work remains, even though the associated points might not be recorded as having been "earned" in a sprint.
In Scrum, points are just for helping a team to estimate how much work they can take on and for giving an indication of how much is currently thought to be left. No-one should give a hoot whether points are recorded against the Sprint itself, or if the Product Backlog is simply reduced in size to show the work now believed to be remaining.
In Scrum the measure of success lies in the incremental delivery of potentially releasable value to a Product Owner. Unfortunately, selling that concept to management can be hard. Often power remains vested in old-style managers who use proxy measures, such as points, to imply progress in a traditionally stage-gated development phase.
Management can be keen to adopt agile terminology but will often shy away from the substance. A common symptom of this is the tracking of how many points are "earned" by a team in a sprint instead of looking to the Product Owner for ROI. Being prepared to ditch these shenanigans in favor of genuine agile change is the acid test of a Scrum transformation.
In a little twist to the original question, we had a user story that was estimated to be of 13 story points. It was a new piece of work that had never been done or documented within the organization and needed more work than originally understood or estimated. As a result, it was not finished in that sprint. When it was brought into the next sprint, it was re-estimated as a 20 pointer simply because of the new data that analysis and consultation uncovered. What are your thoughts on this?
Estimates should be updated so a team can make the best forecast of what will be delivered in the sprint, and of how much work will likely remain in the Product Backlog. That's broadly what you seem to have done in this case, which is good. I assume you kept the Product Owner appraised of the changing situation throughout the Sprint, and that any necessary replanning was done in order to meet the Sprint Goal.
However I'd question why the story was brought into the Sprint in the first place, considering the lack of clarity over the work that would be involved. In such situations a time-boxed development spike is often best. This limits the risk to the Sprint, and helps set realistic expectations about what can and will be delivered.
If this piece of work was really "new" for you, maybee you should had a 1 or 2 days Spike before giving the first 13 points estimate ?
This story was probably very unclear for you, and I won't have accept it in my Sprint BackLog.
We had many grooming sessions for it, to the point that the team felt confident enough to take it on. Once they started coding it however, they came across better approaches and more enhancements that would be of value to the end product. Architecture could have been involved earlier on as well. In hindsight, it does look like we were not ready to take on the story, but it didn't seem that way at the time. A technical spike also would have been an option.
I am not sure if there are other threads on this topic (stories started but not finished in a sprint), but would like to add some color to this. Fundamentally, story points are to determine complexity in completing a story, and prioritization of the story reflects the inherent value of that story.
We handle stories in a sprint the following way:
1) if started but not completed, it is returned to the product backlog and not resized. If taken it is taken into another sprint and completed, points get assigned to that sprint. The average velocity will account for this shift of points.
2) if not started, returned to the backlog and can be decomposed and resized.
> if started but not completed, it is returned to the product backlog
> and not resized. If taken it is taken into another sprint and
> completed, points get assigned to that sprint.
The Product Backlog ought to show the work that is believed to remain, so if work has been "done" then this should be reflected in updated estimates. Bear in mind also that however unreleased work is accounted for, it can be expected to accrue technical debt.
Therefore rather than "assigning points to a Sprint" (which makes little sense in Scrum, where only the deliver of value counts), it may be better to have an accurate forecast of the work remaining (including any technical debt accruing), and to simply acknowledge that the expected scope of work has now changed.