Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Splitting the stories and points treatment
Last Post 19 Mar 2014 12:37 PM by Jenny Aldrin. 8 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
santosh ladde
New Member
New Member
Posts:1
santosh ladde

--
05 Mar 2014 07:04 AM
    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?

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1607
    Ian Mitchell

    --
    05 Mar 2014 07:52 AM
    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.
    Philipp Eisbacher
    New Member
    New Member
    Posts:35
    Philipp Eisbacher

    --
    07 Mar 2014 11:10 PM
    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.

    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1607
    Ian Mitchell

    --
    08 Mar 2014 12:17 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1607
    Ian Mitchell

    --
    16 Mar 2014 02:25 AM
    > 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.
    Jenny Aldrin
    New Member
    New Member
    Posts:17
    Jenny Aldrin

    --
    17 Mar 2014 02:03 PM
    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?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1607
    Ian Mitchell

    --
    17 Mar 2014 02:47 PM
    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.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:247
    Olivier Ledru

    --
    19 Mar 2014 06:29 AM
    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.
    Jenny Aldrin
    New Member
    New Member
    Posts:17
    Jenny Aldrin

    --
    19 Mar 2014 12:37 PM
    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.
    You are not authorized to post a reply.


    Feedback